[Dovecot] Kerberos/GSSAPI auth via .k5login file

[Ben Morrow]

At  4PM +0100 on 28/12/12 you (Jörg Herzinger) wrote:
> Hi, we are currently moving our mailserver to a new server with Dovecot, 
> virtual users in LDAP, Passwords in Kerberos Setup. Everything works 
> fine except for GSSAPI which seems to be a bit buggy.
> 
> The thing is, that when using a .k5login [1] file it seems that SASL 
> does not get passed the home directory specified userdb. In other words, 
> mails for user1 (see below) are stored in /home/domain.at/user1, while 
> the home dir defined in LDAP is /afs/domain.at/home/user1 (virtual 
> users, so only dovecot, not the system does know about this user and 
> home dir). If I do create a .k5login file in /home/domain.at/user1 with 
> the content "someotheruser at DOMAIN.AT", then someotheruser should be able 
> to authenticate himself as user1 via GSSAPI. However, this .k5login file 
> is completely ignored. So it seems to me that the home is not passed on 
> to SASL.

That is correct. Dovecot's handling of .k5login is currently implemented
by calling your system's krb5_kuserok or equivalent with the name of the
system user Dovecot will be using. This means it's not possible to use
.k5login (or cross-realm auth, I would assume) unless you're using
system users.

I've been wondering for a while about patching Dovecot to support its
own krb5 ACL file under the Dovecot directory, not least because it
would be useful to be able to give a principal IMAP access without
necessarily giving it shell access, but it's not entirely
straightforward since currently Dovecot verifies the Kerberos creds
before it even tries to look up the user in the userdb.

(Actually I've been thinking along the lines of some sort of 'authdb',
parallel to the pass- and userdbs, which would subsume both kuserok and
the current master user stuff, but I haven't had a chance yet to try a
concrete implementation.)

Ben