Document URL: https://access.redhat.com/documentation/en-us/red_hat_satellite/6.10/html/administering_red_hat_satellite/chap-administering-configuring_external_authentication#configuring-direct-ad-integration-with-gss-proxy_admin

Section Number and Name: 13.3.3 Configuring Direct AD Integration with GSS-proxy

Describe the issue: The instructions at step 5 (code box 5 in the Procedure section) set gssproxy to point to `/etc/krb5.keytab` as its keytab:
====
5. Create the /etc/gssproxy/00-http.conf file with the following content:

[service/HTTP]
mechs = krb5
cred_store = keytab:/etc/krb5.keytab <===== pointing to krb5.keytab
====

...but the next step, instead, points to `/etc/httpd/conf/http.keytab` when downloading the key from AD to the keytab:
====
6. Create a keytab entry:

1. KRB5_KTNAME=FILE:/etc/httpd/conf/http.keytab net ads keytab add HTTP -U administrator -d3 -s /etc/net-keytab.conf
2. chown root.apache /etc/httpd/conf/http.keytab
3. chmod 640 /etc/httpd/conf/http.keytab
   ====

This causes the right key to reside in a keytab that is not the one used by gssproxy, thus rendering kerberos auth with gssproxy permanently unsuccessful on Satellite.

Suggestions for improvement: Modify step #5 to point to /etc/httpd/conf/http.keytab as below:
====
5. Create the /etc/gssproxy/00-http.conf file with the following content:

[service/HTTP]
mechs = krb5
cred_store = keytab:/etc/httpd/conf/http.keytab <==== point to http.keytab
cred_store = ccache:/var/lib/gssproxy/clients/krb5cc_%U
euid = ID_of_Apache_User
====

Additional information: This bug is present since "forever" so it would be even better if we could fix the docs for all Satellite releases we currently support.