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?

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:

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/ &
[1] 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...).

FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

Reply via email to