[Dovecot] Kerberos/GSSAPI auth via .k5login file
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. If I do add ldap to my nsswitch (for testing only) I additionally have real system users. Now if I create a .k5login in their home defined in LDAP which now also the system knows about everything works just fine. It is still the wrong home since its the one in LDAP and not the one defined by dovecot but at least it shows that our setup is working. See also debug log output below, a failed GSSAPI attempt produces no log output at all.
Our System is Debian Wheezy on an amd64 (virtualized), dovecot Version 2.1.7, filesystem is ext4. Everything is tested with Firefox 17.0 on an Ubuntu Lucid client.
Example LDAP user (not all of it...):
dn: uid=user1,ou=people,dc=domain,dc=at structuralObjectClass: inetOrgPerson objectClass: inetOrgPerson objectClass: posixAccount objectClass: qmailUser uid: username uidNumber: 12345 gidNumber: 100 mail: username@domain.at homeDirectory: /afs/domain.at/home/user1 userPassword: {sasl}user1@DOMAIN.AT
And our dovecot userdb/passdb looks like this:
root@mail201212 /etc/dovecot (git)-[master] # cat conf.d/10-auth.conf auth_gssapi_hostname = "$ALL" auth_krb5_keytab = /etc/dovecot/imap_smtp_mail201212.keytab auth_mechanisms = plain gssapi
!include auth-virtual.conf.ext
root@mail201212 /etc/dovecot (git)-[master] # cat conf.d/auth-virtual.conf.ext mail_uid = mailowner mail_gid = mailowner
userdb { driver = ldap args = /etc/dovecot/ldap-userdb-user_g2.conf.ext } passdb { driver = pam }
root@mail201212 /etc/dovecot (git)-[master] # cat /etc/dovecot/ldap-userdb-user_g2.conf.ext #http://www.postfix.org/ldap_table.5.html hosts = ldap1 ldap2
base = ou=people,dc=domain,dc=at
user_attrs = uid=home=/home/domain.at/%$ user_filter = (&(objectClass=inetOrgPerson)(|(mail=%u)(mailalternateaddress=%u)(uid=%u)))
Debug log output with system users (testing only) and a working GSSAPI auth:
Dec 28 14:18:40 mail201212 dovecot: auth: Debug: Loading modules from directory: /usr/lib/dovecot/modules/auth Dec 28 14:18:40 mail201212 dovecot: auth: Debug: Module loaded: /usr/lib/dovecot/modules/auth/libdriver_mysql.so Dec 28 14:18:40 mail201212 dovecot: auth: Debug: Module loaded: /usr/lib/dovecot/modules/auth/libdriver_pgsql.so Dec 28 14:18:40 mail201212 dovecot: auth: Debug: Module loaded: /usr/lib/dovecot/modules/auth/libdriver_sqlite.so Dec 28 14:18:40 mail201212 dovecot: auth: Debug: Loading modules from directory: /usr/lib/dovecot/modules/auth Dec 28 14:18:40 mail201212 dovecot: auth: Debug: Module loaded: /usr/lib/dovecot/modules/auth/libmech_gssapi.so Dec 28 14:18:40 mail201212 dovecot: auth: Debug: Loading modules from directory: /usr/lib/dovecot/modules/auth Dec 28 14:18:40 mail201212 dovecot: auth: Debug: Module loaded: /usr/lib/dovecot/modules/auth/libauthdb_ldap.so Dec 28 14:18:40 mail201212 dovecot: auth: Debug: passwd-file /etc/dovecot/shared_users: Read 1 users in 0 secs Dec 28 14:18:40 mail201212 dovecot: auth: Debug: auth client connected (pid=11875) Dec 28 14:18:41 mail201212 dovecot: auth: Debug: client in: AUTH#0111#011GSSAPI#011service=imap#011secured#011session=1RaMgOnRZADAqCoq#011lip=192.168.43.100#011rip=192.168.42.42#011lport=993#011rport=55140 Dec 28 14:18:41 mail201212 dovecot: auth: Debug: gssapi(?,192.168.42.42,<1RaMgOnRZADAqCoq>): Using all keytab entries Dec 28 14:18:41 mail201212 dovecot: auth: Debug: client out: CONT#0111#011 Dec 28 14:18:41 mail201212 dovecot: auth: Debug: client in: CONT<hidden> Dec 28 14:18:41 mail201212 dovecot: auth: Debug: gssapi(user1@domain.at,192.168.42.42,<1RaMgOnRZADAqCoq>): security context state completed. Dec 28 14:18:41 mail201212 dovecot: auth: Debug: client out: CONT#0111#011YIGZBgkqhkiG9xIBAgICAG+BiTCBhqADAgEFoQMCAQ+iejB4oAMCARKicQRvMQu0Yxgom2SVOHW25FpxDbqalw/8nuMN1XH78FJUzJ/7CIv9dlQNUrKjFywqS9kNOxQY2sJR 7Ii0hw3i7BGV3VPmoeRJOsbYD5ahBh74NKqxdacN6rLj/cO5vWCee6Oel3rPgLV8kEcOVZOdAt6y Dec 28 14:18:41 mail201212 dovecot: auth: Debug: client in: CONT<hidden> Dec 28 14:18:41 mail201212 dovecot: auth: Debug: gssapi(user1@domain.at,192.168.42.42,<1RaMgOnRZADAqCoq>): Negotiated security layer Dec 28 14:18:41 mail201212 dovecot: auth: Debug: client out: CONT#0111#011BQQF/wAMAAAAAAAAC5QPNQH///+qs6lgevrvypjd1l4= Dec 28 14:18:41 mail201212 dovecot: auth: Debug: client in: CONT<hidden> Dec 28 14:18:41 mail201212 dovecot: auth: Debug: client out: OK#0111#011user=user1 Dec 28 14:18:41 mail201212 dovecot: auth: Debug: master in: REQUEST#0111935278081#01111875#0111#0118d08e90a585981154d7c045ca230b1f9 Dec 28 14:18:41 mail201212 dovecot: auth: Debug: ldap(user1,192.168.42.42,<1RaMgOnRZADAqCoq>): user search: base=ou=people,dc=domain,dc=at scope=subtree filter=(&(objectClass=inetOrgPerson)(|(mail=user1)(mailalternateaddress=user1)(uid=user1))) fields=uid Dec 28 14:18:41 mail201212 dovecot: auth: Debug: ldap(user1,192.168.42.42,<1RaMgOnRZADAqCoq>): result: uid=user1 Dec 28 14:18:41 mail201212 dovecot: auth: Debug: master out: USER#0111935278081#011user1#011home=/home/domain.at/user1 Dec 28 14:18:41 mail201212 dovecot: imap-login: Login: user=<user1>, method=GSSAPI, rip=192.168.42.42, lip=192.168.43.100, mpid=11878, TLS, session=<1RaMgOnRZADAqCoq> Dec 28 14:18:41 mail201212 dovecot: imap(user1): Debug: Effective uid=996, gid=997, home=/home/domain.at/user1 Dec 28 14:18:41 mail201212 dovecot: imap(user1): Debug: Namespace inbox: type=private, prefix=, sep=/, inbox=yes, hidden=no, list=yes, subscriptions=yes location=maildir:~/maildir Dec 28 14:18:41 mail201212 dovecot: imap(user1): Debug: maildir++: root=/home/domain.at/user1/maildir, index=, control=, inbox=/home/domain.at/user1/maildir, alt= Dec 28 14:18:41 mail201212 dovecot: imap(user1): Debug: Namespace : type=public, prefix=PublicLists/, sep=/, inbox=no, hidden=no, list=yes, subscriptions=no location=maildir:/home/listcaptor/maildir/ Dec 28 14:18:41 mail201212 dovecot: imap(user1): Debug: maildir++: root=/home/listcaptor/maildir, index=, control=, inbox=, alt=
[1] http://web.mit.edu/kerberos/krb5-current/doc/user/user_config/k5login.html
-- Jörg Herzinger - EDV Team
GLOBAL 2000 - Friends of the Earth Austria
Neustiftgasse 36, A-1070 Wien tel +43-699-14200030
Dieses Mail wurde mit Oekostrom und Opensource Software erstellt.
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
On 31.12.2012, at 2.26, Ben Morrow ben@morrow.me.uk wrote:
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.
I'm not entirely sure what it would need to do, but I'm pretty sure that code belongs to passdb. mech-gssapi.c already does a passdb lookup, and it could be moved to be done earlier if wanted.
participants (3)
-
Ben Morrow
-
Jörg Herzinger
-
Timo Sirainen