[Dovecot] dovecot 1.2rc5 fails to authenticate user via GSSAPI
Hi,
we're facing problem where dovecot 1.2rc5 is not able to authenticate user via gssapi. (I'm forwarding information from red hat's bugzilla)
Steps to reproduce:
- Install dovecot with kerberos support, create mailboxes for the client
- Get initial credentials on client side
- Attempt to log in via dovecot using gssapi -> login failed
Client side
- Email client displays: "[AUTHENTICATIONFAILED] Authentication failed."
- klist before login shows: Valid starting Expires Service principal 06/18/09 20:01:01 06/19/09 20:01:01 krbtgt/realm@realm
- klist after login attempt shows: Valid starting Expires Service principal 06/18/09 20:01:01 06/19/09 20:01:01 krbtgt/realm@realm 06/18/09 20:01:28 06/19/09 20:01:01 imap/mail.domain@realm
Server side
- /var/log/maillog: dovecot: auth(default): gssapi(user,192.168.0.1): authn_name not authorized dovecot: imap-login: Aborted login (auth failed, 1 attempts): user=<user>, method=GSSAPI, rip=192.168.0.1, lip=192.168.0.2, TLS
It is possible for the same user to login via other mechanisms. The issue reproduced with different email clients. Evolution and a custom java-based client were attempted.
example of dovecot.conf: protocols = imap mail_location = maildir:/home/virtual/%u/Maildir protocol imap { } auth_krb5_keytab=/etc/dovecot.keytab auth default { mechanisms = gssapi userdb static { args = uid=vmail gid=vmail home=/home/virtual/%u } }
Exactly the same dovecot setup was working just fine with dovecot 1.1 series. Authentication using kinit works just fine and kerberos infrastructure is functioning well as I use kerberos auth for other services like apache and ssh successfully.
/var/log/maillog with using auth_debug=yes can be found here: https://bugzilla.redhat.com/attachment.cgi?id=348710
Regards, Michal Hlavinka
On Jun 24, 2009, at 9:38 AM, Michal Hlavinka wrote:
we're facing problem where dovecot 1.2rc5 is not able to
authenticate user via gssapi. (I'm forwarding information from red hat's bugzilla)
I guess it has to be because of these patches:
http://hg.dovecot.org/dovecot-1.2/rev/ff6378d7b209 http://hg.dovecot.org/dovecot-1.2/rev/601e0382b442
Could you try reverting them and see if it helps?
On Wednesday 24 June 2009 17:15:31 Timo Sirainen wrote:
On Jun 24, 2009, at 9:38 AM, Michal Hlavinka wrote:
we're facing problem where dovecot 1.2rc5 is not able to authenticate user via gssapi. (I'm forwarding information from red hat's bugzilla)
I guess it has to be because of these patches:
http://hg.dovecot.org/dovecot-1.2/rev/ff6378d7b209 http://hg.dovecot.org/dovecot-1.2/rev/601e0382b442
Could you try reverting them and see if it helps?
ok, I'll try it asap
On Thursday 25 June 2009 06:54:48 Michal Hlavinka wrote:
On Wednesday 24 June 2009 17:15:31 Timo Sirainen wrote:
On Jun 24, 2009, at 9:38 AM, Michal Hlavinka wrote:
we're facing problem where dovecot 1.2rc5 is not able to authenticate user via gssapi. (I'm forwarding information from red hat's bugzilla)
I guess it has to be because of these patches:
http://hg.dovecot.org/dovecot-1.2/rev/ff6378d7b209 http://hg.dovecot.org/dovecot-1.2/rev/601e0382b442
Could you try reverting them and see if it helps?
ok, I'll try it asap
when I revert those two patches, it works
On Wed, 2009-06-24 at 15:38 +0200, Michal Hlavinka wrote:
dovecot: auth(default): gssapi(user,192.168.0.1): authn_name not authorized
Can you try what it says with these patches:
http://hg.dovecot.org/dovecot-1.2/rev/4172004c1958 http://hg.dovecot.org/dovecot-1.2/rev/a5c5a912769e
On Tue, 2009-07-07 at 20:20 -0400, Timo Sirainen wrote:
On Wed, 2009-06-24 at 15:38 +0200, Michal Hlavinka wrote:
dovecot: auth(default): gssapi(user,192.168.0.1): authn_name not authorized
Can you try what it says with these patches:
http://hg.dovecot.org/dovecot-1.2/rev/4172004c1958 http://hg.dovecot.org/dovecot-1.2/rev/a5c5a912769e
With those patches you also need auth_debug=yes to get everything logged.
On Tue, 2009-07-07 at 20:29 -0400, Timo Sirainen wrote:
On Tue, 2009-07-07 at 20:20 -0400, Timo Sirainen wrote:
On Wed, 2009-06-24 at 15:38 +0200, Michal Hlavinka wrote:
dovecot: auth(default): gssapi(user,192.168.0.1): authn_name not authorized
Can you try what it says with these patches:
http://hg.dovecot.org/dovecot-1.2/rev/4172004c1958 http://hg.dovecot.org/dovecot-1.2/rev/a5c5a912769e
With those patches you also need auth_debug=yes to get everything logged.
I guess this fixes it again: http://hg.dovecot.org/dovecot-1.2/rev/f4ff64dd79a9
On Wednesday 08 July 2009 03:06:08 Timo Sirainen wrote:
On Tue, 2009-07-07 at 20:29 -0400, Timo Sirainen wrote:
On Tue, 2009-07-07 at 20:20 -0400, Timo Sirainen wrote:
On Wed, 2009-06-24 at 15:38 +0200, Michal Hlavinka wrote:
dovecot: auth(default): gssapi(user,192.168.0.1): authn_name not authorized
Can you try what it says with these patches:
http://hg.dovecot.org/dovecot-1.2/rev/4172004c1958 http://hg.dovecot.org/dovecot-1.2/rev/a5c5a912769e
With those patches you also need auth_debug=yes to get everything logged.
I guess this fixes it again: http://hg.dovecot.org/dovecot-1.2/rev/f4ff64dd79a9
should I try it only with these 3 patches or even with the last one? http://hg.dovecot.org/dovecot-1.2/rev/5d9eab092e97
On Wednesday 08 July 2009 03:06:08 Timo Sirainen wrote:
On Tue, 2009-07-07 at 20:29 -0400, Timo Sirainen wrote:
On Tue, 2009-07-07 at 20:20 -0400, Timo Sirainen wrote:
On Wed, 2009-06-24 at 15:38 +0200, Michal Hlavinka wrote:
dovecot: auth(default): gssapi(user,192.168.0.1): authn_name not authorized
Can you try what it says with these patches:
http://hg.dovecot.org/dovecot-1.2/rev/4172004c1958 http://hg.dovecot.org/dovecot-1.2/rev/a5c5a912769e
With those patches you also need auth_debug=yes to get everything logged.
I guess this fixes it again: http://hg.dovecot.org/dovecot-1.2/rev/f4ff64dd79a9
We've tested dovecot with all four available patches (it means up to date mech-gssapi.c ) and it wokrs.
Thanks!
On Wed, 2009-07-08 at 13:41 +0200, Michal Hlavinka wrote:
I guess this fixes it again: http://hg.dovecot.org/dovecot-1.2/rev/f4ff64dd79a9
We've tested dovecot with all four available patches (it means up to date mech-gssapi.c ) and it wokrs.
I've been talking with the main Heimdal guy and he thinks that kind of checking is scary bad.
One thing that should change at least is that gss_display_name() shouldn't be passed to krb5_parse_name(). Instead gss_export_name() should be used and its results checked and passed to krb5_parse_name() (OpenSSH does this too). But I don't know if that would solve the original problem that required me to add the patch mentioned above.
One thing I'm not really sure about in Kerberos is, does both MIT and Heimdal require that you are using system users and to have NSS set up in a way that Kerberos code can look up users with getpw*() functions? I think that's the main thing that krb5_kuserok() does that gss_compare_name() doesn't. But does Kerberos do the same check elsewhere and this isn't really a problem after all? If it doesn't check user's existence elsewhere, maybe I could just use gss_export_name()s and compare them instead of display names?..
On Fri, 2009-07-17 at 19:33 -0400, Timo Sirainen wrote:
One thing I'm not really sure about in Kerberos is, does both MIT and Heimdal require that you are using system users and to have NSS set up in a way that Kerberos code can look up users with getpw*() functions?
Ah, looking at the original mail it uses userdb static. So this getpw*() stuff is clearly the problem here. I'll talk to the Heimdal guy more :)
On 18.07.2009 3:47, Timo Sirainen wrote:
On Fri, 2009-07-17 at 19:33 -0400, Timo Sirainen wrote:
One thing I'm not really sure about in Kerberos is, does both MIT and Heimdal require that you are using system users and to have NSS set up in a way that Kerberos code can look up users with getpw*() functions?
Ah, looking at the original mail it uses userdb static. So this getpw*() stuff is clearly the problem here. I'll talk to the Heimdal guy more :)
Feel free to post this on comp.protocols.kerberos, to make sure you cover every aspect of work with both MIT and Heimdal.
I guess this fixes it again: http://hg.dovecot.org/dovecot-1.2/rev/f4ff64dd79a9
We've tested dovecot with all four available patches (it means up to date mech-gssapi.c ) and it wokrs.
I've been talking with the main Heimdal guy and he thinks that kind of checking is scary bad.
One thing that should change at least is that gss_display_name() shouldn't be passed to krb5_parse_name(). Instead gss_export_name() should be used and its results checked and passed to krb5_parse_name() (OpenSSH does this too). But I don't know if that would solve the original problem that required me to add the patch mentioned above.
One thing I'm not really sure about in Kerberos is, does both MIT and Heimdal require that you are using system users and to have NSS set up in a way that Kerberos code can look up users with getpw*() functions? I think that's the main thing that krb5_kuserok() does that gss_compare_name() doesn't. But does Kerberos do the same check elsewhere and this isn't really a problem after all? If it doesn't check user's existence elsewhere, maybe I could just use gss_export_name()s and compare them instead of display names?..
Unfortunately my Kerberos knowledge is almost equal to zero, so I can't help with theory, sorry.
participants (3)
-
Michal Hlavinka
-
Nikolay Shopik
-
Timo Sirainen