dovecot - May 2013 - Crossrealm Kerberos problems

I am running dovecot 2.1.7 on Debian Squeeze 64 bit, config information
at the end of the email.

I am working on a Kerberos/GSSAPI based setup that requires cross-realm
authentication.  I have regular GSSAPI working, I can log in using
pam_krb5 with password based logins or with the GSSAPI support when
using a kerberos ticket in the default realm.

However when I attempt to authenticate using cross realm authentication
the login fails (logs below).

After perusing the source code I beleive that the problem is as such:

All taking place in mech-gssapi.c

1. mech_gssapi_userok(...) calls mech_gssapi_krb5_userok
2. mech_gssapi_krb5_userok(...) calls krb5_kuserok(...) to verify that
the given Kerberos prinicpal can log in as the requested user.
3. The authentication process is running as the Dovecot user so:
  3a. krb5_kuserok(...) looks for ~dovecot/.k5login to authorize cross
realm logins
  3b. There is no ~dovecot/.k5login, thus no cross realm access is allowed
  3c. It should be looking at the users .k5login ~poptest/.k5login
  3d. This never happens and the login attempt fails


I have the server set up to use system users specifically so that I can
do cross-realm authentication.

Do I have some basic configuration error?  How do I change the
authentication process to run as the user requesting to login?  Should
that be allowed?

Another thought is to backport some of the patches proposed for 2.2 that
remove krb5_kuserok from the loop.

Thank you for any insight.  This server is not in production use so I
can experiment.


May  9 10:54:49 lakeview.ligo-wa.caltech.edu dovecot: auth: Debug:
gssapi(jonathan.hanks at SOME.REALM,198.129.xxx.xxx,<qYAkv0zc9wDGgdAT>):
Negotiated security layer
May  9 10:54:49 lakeview.ligo-wa.caltech.edu dovecot: auth: Debug:
gssapi(jonathan.hanks at SOME.REALM,198.129.xxx.xxx,<qYAkv0zc9wDGgdAT>):
Negotiated security layer
May  9 10:54:49 lakeview.ligo-wa.caltech.edu dovecot: auth: Debug:
client out: CONT#0111#011BQQF/wAMAAAAAAAACpxNKQH///+YdY3lGMDBq6TWTfcMay  9
10:54:49 lakeview.ligo-wa.caltech.edu dovecot: auth: Debug:
client out: CONT#0111#011BQQF/wAMAAAAAAAACpxNKQH///+YdY3lGMDBq6TWTfcMay  9
10:54:49 lakeview.ligo-wa.caltech.edu dovecot: auth: Debug:
client in: CONT<hidden>
May  9 10:54:49 lakeview.ligo-wa.caltech.edu dovecot: auth: Debug:
client in: CONT<hidden>
May  9 10:54:49 lakeview.ligo-wa.caltech.edu dovecot: auth:
gssapi(jonathan.hanks at SOME.REALM,198.129.xxx.xxx,<qYAkv0zc9wDGgdAT>):
User not authorized to log in as poptest
May  9 10:54:49 lakeview.ligo-wa.caltech.edu dovecot: auth:
gssapi(jonathan.hanks at SOME.REALM,198.129.xxx.xxx,<qYAkv0zc9wDGgdAT>):
User not authorized to log in as poptest


My config is as follows:

# 2.1.7: /etc/dovecot/dovecot.conf
# OS: Linux 2.6.32-5-amd64 x86_64 Debian 6.0.7
auth_debug = yes
auth_gssapi_hostname = $ALL
auth_krb5_keytab = /etc/mail.keytab
auth_mechanisms = plain login gssapi
auth_username_format = %u
auth_verbose = yes
listen = *
mail_location = mbox:~/mail:INBOX=/var/spool/mail/inbox/%u
mail_privileged_group = mail
passdb {
  args = dovecot
  driver = pam
}
protocols = imap pop3
service auth {
  unix_listener /var/spool/postfix/private/auth {
    group = postfix
    mode = 0666
    user = postfix
  }
  unix_listener auth-userdb {
    mode = 0666
  }
}
service imap-login {
  inet_listener imap {
    port = 0
  }
  inet_listener imaps {
    port = 993
    ssl = yes
  }
}
service pop3-login {
  inet_listener pop3 {
    port = 0
  }
  inet_listener pop3s {
    port = 995
    ssl = yes
  }
}
ssl_cert = </etc/ssl/certs/mail-server.pem
ssl_cipher_list = !aNULL:!eNULL:!EXPORT:!DSS:!DES:RC4-SHA:RC4-MD5:ALL
ssl_key = </etc/ssl/private/mail-server.pem
userdb {
  driver = passwd
}
protocol imap {
  imap_client_workarounds = tb-extra-mailbox-sep tb-lsub-flags
}
protocol pop3 {
  pop3_client_workarounds = outlook-no-nuls oe-ns-eoh
  pop3_uidl_format = %08Xu%08Xv
}

-- 
Jonathan Hanks
General Computing Sys Admin
LIGO Hanford Observatory

On 9.5.2013, at 21.13, Jonathan Hanks <hanks_j at ligo-wa.caltech.edu>
wrote:
> I am working on a Kerberos/GSSAPI based setup that requires cross-realm
> authentication.  I have regular GSSAPI working, I can log in using
> pam_krb5 with password based logins or with the GSSAPI support when
> using a kerberos ticket in the default realm.
MIT or Heimdal?
> However when I attempt to authenticate using cross realm authentication
> the login fails (logs below).
> 
> After perusing the source code I beleive that the problem is as such:
> 
> All taking place in mech-gssapi.c
> 
> 1. mech_gssapi_userok(...) calls mech_gssapi_krb5_userok
> 2. mech_gssapi_krb5_userok(...) calls krb5_kuserok(...) to verify that
> the given Kerberos prinicpal can log in as the requested user.
> 3. The authentication process is running as the Dovecot user so:
>  3a. krb5_kuserok(...) looks for ~dovecot/.k5login to authorize cross
> realm logins
>  3b. There is no ~dovecot/.k5login, thus no cross realm access is allowed
>  3c. It should be looking at the users .k5login ~poptest/.k5login
>  3d. This never happens and the login attempt fails
Heimdal's man page seems to say that it's first looking up the system
user and using .k5login from that user's home dir. MIT's man page
doesn't really say anything.
> I have the server set up to use system users specifically so that I can
> do cross-realm authentication.
> 
> Do I have some basic configuration error?  How do I change the
> authentication process to run as the user requesting to login?  Should
> that be allowed?
If the auth process is running as root, you could patch the code to do that ..
but seems pretty ugly to me.
> Another thought is to backport some of the patches proposed for 2.2 that
> remove krb5_kuserok from the loop.
With v2.2 there's a "k5principals" passdb extra field that you can
set, which lists all the authorized users.