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?