service/HTTP example: why use a separate keytab?
by James Ralston
I don't understand the example of using gssproxy for HTTP access:
[service/HTTP]
mechs = krb5
cred_store = keytab:/etc/gssproxy/http.keytab
cred_store = ccache:/var/lib/gssproxy/clients/krb5cc_%U
euid = 48
If I'm going to create a separate keytab file for HTTP, then wouldn't
it be easier to make the keytab file mode 0600, owner apache, group
apache, and not bother with gssproxy at all? I mean, at that point,
what advantage is there to using gssproxy?
Wouldn't a better example be using gssproxy to permit apache to obtain
HTTP credentials (and only HTTP) out of the default system keytab
file (/etc/krb5.keytab), without having to make the keytab file
readable for apache? Something like:
[service/HTTP]
mechs = krb5
cred_store = keytab:/etc/krb5.keytab
cred_store = ccache:/var/lib/gssproxy/clients/krb5cc_%U
euid = 48
krb5_principal = HTTP
Or am I misunderstanding what krb5_principal does?
For sites that join Linux hosts to Microsoft Active Directory (and
thus create host credentials) by using "net ads join", there is a huge
advantage to keeping all of the credentials in the system keytab: if
Samba is configured to store host credentials using the system keytab
(i.e., /etc/samba/smb.conf has "kerberos method = system keytab"),
then "net ads changetrustpw" will update all host credentials.
But if different credentials are stored in different keytabs, then ~24
hours after "net ads changetrustpw" is executed, all credentials not
stored in the system keytab will become invalid. :-(
Therefore, for Microsoft AD sites, storing all credentials in the
system keytab (/etc/krb5.keytab) is vastly preferable. Even for sites
not using Microsoft AD, storing the credentials in a single keytab
file and using gssproxy to broker access to specific credentials seems
like a better idea than using multiple keytab files.
Is there something I'm missing here?
8 years, 5 months
help with debugging gssproxy with NFS server?
by James Ralston
Hello all,
I cannot get Kerberos security working on an NFSv4 server I'm setting
up on RHEL7, using sssd with Microsoft Active Directory. The problem
seems to lie with gssproxy. But I'm having a very difficult time with
debugging.
gssproxy has a "-d" flag that enables debugging. But it is pretty
much useless. :-( The only additional information it syslogs is:
Nov 13 15:00:08 server gssproxy: gp_rpc_execute: executing 9
(GSSX_ACCEPT_SEC_CONTEXT) for service "nfs-server", euid: 0, socket:
/run/gssproxy.sock
Nov 13 15:00:08 server rpc.gssd[4921]: destroying client
/var/lib/nfs/rpc_pipefs/nfsd4_cb/clnt2
If I strace the gssproxy daemon, I see error messages like this:
2464 open("/var/lib/nfs/rpc_pipefs/nfsd4_cb/clnta/krb5", O_RDWR) = -1
ENOENT (No such file or directory)
2464 open("/var/lib/nfs/rpc_pipefs/nfsd4_cb/clnta/gssd", O_RDWR) = -1
ENOENT (No such file or directory)
But I'm not sure if these errors are important.
If I tcpdump the connection between the client and the server, I see
that the server responds to the client's AP-REQ attempts by simply
closing the TCP connection.
We already have RHEL7 NFSv4 clients that use sec=krb5 with a
commercial NAS NFSv4 server, so I know the basics of configuring NFSv4
with krb5 security. The same client configuration works perfectly
with the NAS server using krb5/krb5i/krb5p security. And I can mount
the Linux NFS server as long as I use sec=sys; it only fails when I
use sec=krb5 as a mount option. So it's very clearly the Kerberos
piece that's failing on the server.
But I have no idea where to go from here, because the debugging
information that gssproxy emits gives me no clues as to what's wrong
on the server.
There has to be some way to get more debugging information than this.
Help?
8 years, 5 months