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...).
Best,
Ray
_______________________________________________
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
