thr3ads.net - dovecot - [Dovecot] Kerberos/GSSAPI auth via .k5login file [Dec 2012]

If this information is useful, please help other people find it:
Share via:

Jörg Herzinger

2012-Dec-28 15:02 UTC

[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 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.
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 at domain.at
homeDirectory: /afs/domain.at/home/user1
userPassword: {sasl}user1 at DOMAIN.AT

And our dovecot userdb/passdb looks like this:
===========================
root at 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 at 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 at 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 at 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 at 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///+qs6lgevrvypjd1l4Dec 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, altDec 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.

Ben Morrow

2012-Dec-31 00:26 UTC

head link

[Dovecot] Kerberos/GSSAPI auth via .k5login file

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

Maybe Matching Threads

Search for more possibly parallel threads

dovecot - Dec 2012 - Kerberos/GSSAPI auth via .k5login file

[Dovecot] Kerberos/GSSAPI auth via .k5login file

[Dovecot] Kerberos/GSSAPI auth via .k5login file

Maybe Matching Threads