[Dovecot] Digest-MD5 and GSSAPI not working in beta3
I have built dovecot with kerberos support, however am not able to log in using GSSAPI support in my mail client. I receive the following error:
SASL(-4): no mechanism available: No worthy mechs found
Additionally, Digest-MD5 does not work - I receive an authentication failed (as though I have an incorrect password) if I try to use it.
I am using PostgreSQL for authentication, and returning a plaintext password with my SQL query. LOGIN, PLAIN, NTLM, and CRAM-MD5 are all working as expected.
I tried making the change shown in Mark Davies' src/auth/mech-gssapi.c patch (posted to the list on 10 February), but it had no effect.
Any advice welcome!
Cheers,
Casey Allen Shobe | cshobe@seattleserver.com | 206-381-2800 SeattleServer.com, Inc. | http://www.seattleserver.com
On Thu, 2006-02-23 at 13:14 +0000, Casey Allen Shobe wrote:
I have built dovecot with kerberos support, however am not able to log in using GSSAPI support in my mail client. I receive the following error:
SASL(-4): no mechanism available: No worthy mechs found
I don't really know about the Kerberos code in Dovecot.. Did you check if there was anything in Dovecot's logs with auth_verbose=yes?
Additionally, Digest-MD5 does not work - I receive an authentication failed (as though I have an incorrect password) if I try to use it.
This could have something to do with realms. I just tested this for a while and it looks like Cyrus SASL client wants to send a realm always, even if Dovecot doesn't advertise any realms.
Are all your usernames in user@domain format? In that case you could set auth_realms to the list of domains. Or alternatively try if the attached patch helps.
On Friday 24 February 2006 10:03, Timo Sirainen wrote:
I don't really know about the Kerberos code in Dovecot.. Did you check if there was anything in Dovecot's logs with auth_verbose=yes?
This could have something to do with realms. I just tested this for a while and it looks like Cyrus SASL client wants to send a realm always, even if Dovecot doesn't advertise any realms.
Are all your usernames in user@domain format? In that case you could set auth_realms to the list of domains. Or alternatively try if the attached patch helps.
I applied the patch - but it makes no difference. I tried adding one of the domains to both auth_realms and default_auth_realm, and it didn't help either.
For reference, here's what I see with PLAIN:
auth(default): client in: AUTH_1_PLAIN_service=IMAP_lip=205.234.78.135_rip=71.113.119.162_resp=<hidden> auth(default): sql(info@xxxx.net,71.113.119.162): query: select "user", "password" from "users" where "user" = 'info@xxxx.net' auth(default): client out: OK_1_user=info@xxxx.net auth(default): master in: REQUEST_3_26029_1 auth(default): master out: USER_3_info@pwci.net_uid=89_gid=89_home=/var/vpopmail/domains/xxxx.net/info imap-login: Login: user=info@xxxx.net, method=PLAIN, rip=71.113.119.162, lip=205.234.78.135
Here's what I see when trying DIGEST-MD5:
auth(default): client in: AUTH_1_DIGEST-MD5_service=IMAP_secured_lip=205.234.78.135_rip=71.113.119.162 auth(default): client out: CONT_1_cmVhbG09IiIsbm9uY2U9Im1LZ2J2WWRYeTNWTFUzZXdFelVPdlE9PSIscW9wPSJhdXRoIixjaGFyc2V0PSJ1dGYtOCIsYWxnb3JpdGhtPSJtZDUtc2VzcyI= auth(default): client in: CONT<hidden> auth(default): sql(kc@xxxx.com,71.113.119.162): query: select "user", "password" from "users" where "user" = 'kc@xxxx.com' auth(default): digest-md5(kc@xxxx.com,71.113.119.162): password mismatch auth(default): client out: FAIL_1_user=kc@xxxx.com imap-login: Disconnected: user=kc@sk8rland.com, method=DIGEST-MD5, rip=71.113.119.162, lip=205.234.78.135, TLS
And this is all I see when trying GSSAPI:
imap-login: Disconnected: rip=71.113.119.162, lip=205.234.78.135
Cheers,
Casey Allen Shobe | cshobe@seattleserver.com | 206-381-2800 SeattleServer.com, Inc. | http://www.seattleserver.com
On Fri, 2006-02-24 at 13:19 +0000, Casey Allen Shobe wrote:
auth(default): digest-md5(kc@xxxx.com,71.113.119.162): password mismatch
Set auth_debug_passwords=yes and see what it prints. You could also try manually to get the crypted password and see why it goes wrong:
dovecotpw -u kc@xxxx.com -s digest-md5
If that doesn't print the same value as what you see in logs, try with -u kc.
This is because with Digest-MD5 the password has is built from both username and password, and they both must match exactly. Hmm. Now that I think of it, this breaks aliases. I guess I'll fix this also. Patch included in attachment, does this help either?
And this is all I see when trying GSSAPI:
imap-login: Disconnected: rip=71.113.119.162, lip=205.234.78.135
So it's not even trying to log in with GSSAPI. You did add it to mechanisms list, right? And it gets advertised in Dovecot's capability reply?
On Friday 24 February 2006 13:41, Timo Sirainen wrote:
On Fri, 2006-02-24 at 13:19 +0000, Casey Allen Shobe wrote:
auth(default): digest-md5(kc@xxxx.com,71.113.119.162): password mismatch
Set auth_debug_passwords=yes and see what it prints.
FWIW, I tried that first without the patch you sent before. Then I saw the realm problem:
auth(default): client in: AUTH_1_DIGEST-MD5_service=IMAP_lip=205.234.78.135_rip=71.113.119.162 auth(default): client out: CONT_1_bm9uY2U9IjRjcUQvRjZhUzJ6UVY3ZGpvSElSMVE9PSIscW9wPSJhdXRoIixjaGFyc2V0PSJ1dGYtOCIsYWxnb3JpdGhtPSJtZDUtc2VzcyI= auth(default): client in: CONT_1_dXNlcm5hbWU9ImtjQHNrOHJsYW5kLmNvbSIscmVhbG09ImltYXAuc2s4cmxhbmQuY29tIixub25jZT0iNGNxRC9GNmFTMnpRVjdkam9ISVIxUT09Iixjbm9uY2U9Inh0bFFKa2oycHYvYVQvd3JFT2hUMnpDN3Y5empHWXlHZ0JvQ0lYMCs1aGs9IixuYz0wMDAwMDAwMSxxb3A9YXV0aCxkaWdlc3QtdXJpPSJpbWFwL2ltYXAuc2s4cmxhbmQuY29tIixyZXNwb25zZT01ZDNmNmFhOThiN2EyMmU5NDQ4ZmU3NTdiMTk4NzkwZA== auth(default): digest-md5(?,71.113.119.162): Invalid realm auth(default): client out: FAIL_1 imap-login: Disconnected: method=DIGEST-MD5, rip=71.113.119.162, lip=205.234.78.135
So I tried with the patched version, and see this:
auth(default): client in: AUTH_1_DIGEST-MD5_service=IMAP_lip=205.234.78.135_rip=71.113.119.162 auth(default): client out: CONT_1_cmVhbG09IiIsbm9uY2U9IkRWQm5MWXhsemxhLzBoSjF0RXdFc1E9PSIscW9wPSJhdXRoIixjaGFyc2V0PSJ1dGYtOCIsYWxnb3JpdGhtPSJtZDUtc2VzcyI= auth(default): client in: CONT_1_dXNlcm5hbWU9ImtjQHNrOHJsYW5kLmNvbSIscmVhbG09IiIsbm9uY2U9IkRWQm5MWXhsemxhLzBoSjF0RXdFc1E9PSIsY25vbmNlPSJNNzFxaGgxbGRWNkFLb1UzM0d5Sk5XY1J2VnI5ak5jaFU1akQ4TUZkWHJRPSIsbmM9MDAwMDAwMDEscW9wPWF1dGgsZGlnZXN0LXVyaT0iaW1hcC9pbWFwLnNrOHJsYW5kLmNvbSIscmVzcG9uc2U9NTQ0OTE0OTNjOTIxOWY3ODQ1NDRhYTIwZTIxNjUyZjc= auth(default): sql(kc@sk8rland.com,71.113.119.162): query: select "user", "password" from "users" where "user" = 'kc@sk8rland.com' auth(default): digest-md5(kc@sk8rland.com,71.113.119.162): password mismatch auth(default): client out: FAIL_1_user=kc@sk8rland.com imap-login: Disconnected: user=kc@sk8rland.com, method=DIGEST-MD5, rip=71.113.119.162, lip=205.234.78.135
You could also try manually to get the crypted password and see why it goes wrong: dovecotpw -u kc@xxxx.com -s digest-md5
# dovecotpw -u kc@sk8rland.com -s digest-md5 Enter new password: <type my password here> Retype new password: <type my password here> {DIGEST-MD5}bc077aef5e9d4a3527e9d21a7d527802
If that doesn't print the same value as what you see in logs, try with -u kc.
Erm, I'm not sure what to look for in the logs, so what the hey:
# dovecotpw -u kc -s digest-md5 Enter new password: Retype new password: {DIGEST-MD5}8ac1882cb154c9c59bfa38111abf8316
This is because with Digest-MD5 the password has is built from both username and password, and they both must match exactly. Hmm. Now that I think of it, this breaks aliases. I guess I'll fix this also. Patch included in attachment, does this help either?
With new patch, got this:
auth(default): client in: AUTH_1_DIGEST-MD5_service=IMAP_lip=205.234.78.135_rip=71.113.119.162 auth(default): client out: CONT_1_cmVhbG09IiIsbm9uY2U9IkdmSytqOHJPbVU1aUJJYWo5ZEMwMXc9PSIscW9wPSJhdXRoIixjaGFyc2V0PSJ1dGYtOCIsYWxnb3JpdGhtPSJtZDUtc2VzcyI= auth(default): client in: CONT_1_dXNlcm5hbWU9ImtjQHNrOHJsYW5kLmNvbSIscmVhbG09IiIsbm9uY2U9IkdmSytqOHJPbVU1aUJJYWo5ZEMwMXc9PSIsY25vbmNlPSJHNVpvY1J6eVRPYnprSXpHM0pSNEh1c2hXV2hvN29qUUduNDV2K0MzZnZjPSIsbmM9MDAwMDAwMDEscW9wPWF1dGgsZGlnZXN0LXVyaT0iaW1hcC9pbWFwLnNrOHJsYW5kLmNvbSIscmVzcG9uc2U9MzJmYzhmYjdiNWZmODk1ODkwZDIxNDUyZjZmYWM3MjI= auth(default): sql(kc@sk8rland.com,71.113.119.162): query: select "user", "password" from "users" where "user" = 'kc@sk8rland.com' auth(default): digest-md5(kc@sk8rland.com,71.113.119.162): password mismatch auth(default): client out: FAIL_1_user=kc@sk8rland.com imap-login: Disconnected: user=kc@sk8rland.com, method=DIGEST-MD5, rip=71.113.119.162, lip=205.234.78.135
So it's not even trying to log in with GSSAPI. You did add it to mechanisms list, right? And it gets advertised in Dovecot's capability reply?
Connected to a.mx. Escape character is '^]'.
- OK [CAPABILITY IMAP4rev1 SORT THREAD=REFERENCES MULTIAPPEND UNSELECT LITERAL+ IDLE CHILDREN NAMESPACE LOGIN-REFERRALS STARTTLS AUTH=PLAIN AUTH=LOGIN AUTH=DIGEST-MD5 AUTH=CRAM-MD5 AUTH=NTLM AUTH=GSSAPI] SeattleServer.com IMAP ready. 2 capability
- CAPABILITY IMAP4rev1 SORT THREAD=REFERENCES MULTIAPPEND UNSELECT LITERAL+ IDLE CHILDREN NAMESPACE LOGIN-REFERRALS STARTTLS AUTH=PLAIN AUTH=LOGIN AUTH=DIGEST-MD5 AUTH=CRAM-MD5 AUTH=NTLM AUTH=GSSAPI 2 OK Capability completed.
root@patos.seattleserver.com:/home/root/dovecot-1.0.beta3 # grep 'mechanisms =' /etc/dovecot.conf mechanisms = plain login digest-md5 cram-md5 ntlm gssapi
-- Casey Allen Shobe | cshobe@seattleserver.com | 206-381-2800 SeattleServer.com, Inc. | http://www.seattleserver.com
participants (2)
-
Casey Allen Shobe
-
Timo Sirainen