On Tue, 2018-02-13 at 19:23 +0100, Ray via FreeIPA-users wrote: > Hi Simo, > > > > Hi Simo, > > > > > > > > Hi there, > > > > > > > > > > I'm trying to make Apache to access a kerberized document root on > > > > > CentOS > > > > > 7 using gssproxy. So far without success. On the web server machine > > > > > (=NFS client) I configured a gss-proxy config file: > > > > > > > > > > # cat /etc/gssproxy/99-nfs-client.conf > > > > > [service/nfs-client] > > > > > mechs = krb5 > > > > > cred_store = keytab:/etc/krb5.keytab > > > > > cred_store = ccache:FILE:/var/lib/gssproxy/clients/krb5cc_%U > > > > > cred_store = client_keytab:/var/lib/gssproxy/clients/%U.keytab > > > > > cred_usage = initiate > > > > > allow_any_uid = yes > > > > > trusted = yes > > > > > euid = 0 > > > > > > > > > > In addition to this I set up a credentials cache > > > > > /var/lib/gssproxy/clients/krb5cc_<httpd uid> > > > > > > > > What did you put in this file? > > > > > > Probably I made a mistake here: I got the keytab from the IPA server > > > and > > > named it /var/lib/gssproxy/clients/krb5cc_<httpd uid> instead of > > > /var/lib/gssproxy/clients/<httpd_uid>.keytab. I fixed that now (by > > > mv'ing it) and ran > > > > > > systemctl stop gssproxy to not have gssproxy as a > > > daemon > > > gssproxy -d -i -C /etc/gssproxy/ & to have gssproxy dump any debug > > > msgs to my terminal > > > > Note that running gssproxy from a root shell makes it run in unconfined > > mode, so later on the files it create may have SELinux contexts that > > are wrong and gssproxy may fail in various ways. > > Ok, right now I switched SELinunx off (setenforce 0) until I have > somehting working... > > > > # klist -ke <httpd uid>.keytab > > > Keytab name: FILE:<httpd uid>.keytab > > > KVNO Principal > > > ---- > > > -------------------------------------------------------------------------- > > > 1 nfs/<nfsserver-fqdn@REALM> (aes256-cts-hmac-sha1-96) > > > 1 nfs/<nfsserver-fqdn@REALM> (aes128-cts-hmac-sha1-96) > > > 1 host/<nfsclient-fqdn@REALM> (aes256-cts-hmac-sha1-96) > > > 1 host/<nfsclient-fqdn@REALM> (aes128-cts-hmac-sha1-96) > > > > This is not the keytab you want most probably. > > You want a keytab with credentials that the server can map to a > > UID/GID, usually that is done for user principals. However the server > > can be configured to map a specific service principal name to a local > > use as well, it's on the server side at this point. > > I removed the above keytab and made a new one with user credentials: > > # klist -ke <httpd-uid>.keytab > Keytab name: FILE:<httpd-uid>.keytab > KVNO Principal > ---- > -------------------------------------------------------------------------- > 2 <httpd-user>@REALM (aes256-cts-hmac-sha1-96) > 2 <httpd-user>@REALM (aes128-cts-hmac-sha1-96) > > This seems insufficient though, 'coz when I mount the NFS docroot > temporarily to /mnt and then "ls -l /" as httpd-user, I get to see this > line: > > d?????????? ? ? ? ? ? mnt > > Which other principals should I add to the keytab? I tried adding the > nfs service principal to the keytab, but that doesn't change this > behavior... Does the order in which I add principals to the keytab > matter in this context?
The first one is picked, and you have all you need there. > klist for httpd-user looks not good either, concering the validy > timestamps (1970...1970), or is that normal?: > > $ klist > Ticket cache: KEYRING:persistent:<httpd uid>:<httpd uid> > Default principal: <httpd-user>@REALM > > Valid starting Expires Service principal > 01/01/1970 01:00:00 01/01/1970 01:00:00 > Encrypted/Credentials/v1@X-GSSPROXY: It is an artifact of how Gssproxy stores credentials for you (in encrypted form), it is normal, not a problem. > > The (null) represents the default socket, not a bug. > > > > Unfortunately the default log level does not show the result of the > > calls, but it is normal to see 2 init context calls, so it seem to be > > working right on the gssproxy side. > > I think there's something not right with gssproxy: when I call it with > --debug-level=3 it still says "level: 0": > > # gssproxy --debug --debug-level=3 -i -C /etc/gssproxy/ & >  17831 > root@nfsclient:/var/lib/gssproxy/clients# [2018/02/13 09:56:20]: Debug > Enabled (level: 0) > > Nevertheless the output becomes extremely verbose (plenty of hex). In > the man-page --debug-level is not mentioned at all (ok, still better > this way than having something promised in the manpage that does not > exist in the binary...). Do you have any logs on the server side ? As far as I can tell the client side (GSSAPI wise at least) is working correctly. Simo. -- Simo Sorce Sr. Principal Software Engineer Red Hat, Inc _______________________________________________ FreeIPA-users mailing list -- email@example.com To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org