[Dovecot] 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
- mech_gssapi_userok(...) calls mech_gssapi_krb5_userok
- mech_gssapi_krb5_userok(...) calls krb5_kuserok(...) to verify that the given Kerberos prinicpal can log in as the requested user.
- 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@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@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///+YdY3lGMDBq6TWTfc= May 9 10:54:49 lakeview.ligo-wa.caltech.edu dovecot: auth: Debug: client out: CONT#0111#011BQQF/wAMAAAAAAAACpxNKQH///+YdY3lGMDBq6TWTfc= 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: Debug: client in: CONT<hidden> May 9 10:54:49 lakeview.ligo-wa.caltech.edu dovecot: auth: gssapi(jonathan.hanks@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@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 =
-- Jonathan Hanks General Computing Sys Admin LIGO Hanford Observatory
On 9.5.2013, at 21.13, Jonathan Hanks hanks_j@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
- mech_gssapi_userok(...) calls mech_gssapi_krb5_userok
- mech_gssapi_krb5_userok(...) calls krb5_kuserok(...) to verify that the given Kerberos prinicpal can log in as the requested user.
- 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.
Answers inline
On 5/15/13 5:47 AM, Timo Sirainen wrote:
On 9.5.2013, at 21.13, Jonathan Hanks hanks_j@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?
MIT Kerberos
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
- mech_gssapi_userok(...) calls mech_gssapi_krb5_userok
- mech_gssapi_krb5_userok(...) calls krb5_kuserok(...) to verify that the given Kerberos prinicpal can log in as the requested user.
- 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.
MIT Kerberos does the same.
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.
Running as root does not seem like a good idea to me either.
What I have done for now is to modify mech-gssapi to read from the users .k5login by replacing krb5_kuserok with custom code. This did require that I change permissions to the user home directories and the .k5login file to be read by the dovecot user. For my case this is not a problem, I can get away with this due to the restrictions I put on the box, however it does not look like a general solution.
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.
I looked at this code. I like having the extra protection of each user mail files being under restricted permissions with separate owners. However, having the mail use system users is not a hard requirement for my setup, having cross realm Kerberos/GSSAPI is a hard requirement.
-- Jonathan Hanks General Computing Sys Admin LIGO Hanford Observatory
participants (2)
-
Jonathan Hanks
-
Timo Sirainen