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@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