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?
