Answers inline On 5/15/13 5:47 AM, Timo Sirainen wrote: > On 9.5.2013, at 21.13, Jonathan Hanks <hank...@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 >> >> 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. 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
