Document URL: https://access.redhat.com/documentation/en-us/red_hat_satellite/6.14/html-single/installing_satellite_server_in_a_connected_network_environment/index#Configuring_Direct_AD_Integration_with_GSS_Proxy_satellite

Section Number and Name:

5.3 Configuring Direct AD Integration with GSS-Proxy

Describe the issue:

Red Hat documentation states: "The traditional process of Kerberos authentication in Apache requires the Apache process to have read access to the keytab file. GSS-Proxy allows you to implement stricter privilege separation for the Apache server by removing access to the keytab file while preserving Kerberos authentication functionality"

However, the instructions then direct the user to place the keytab file in an apache config directory '/etc/httpd/conf'. Doing so give the keytab file an SELinux context of httpd_config_t. This will cause all sorts of SELinux errors since gssproxy will be denied access to the file. The documentation never mentions the SELinux context of the file. Furthermore, the documentation instructs the user to set the group owner of the file to apache, and to give the group read access. This gives the apache user read access to the keytab file, which is the exact oppposite of the purpose for using gssproxy as stated above in the documentation.

Additionally, following the documentation will not result in a working SSO set up using Kerberos, because a Service Principal Name (SPN) must be created in Active Directory in order for Kerberos to work. At no point does the documentation mention creating the "HTTP/servername.example.com" SPN in AD.

Suggestions for improvement:

Move the keytab file to /etc/gssproxy and set the context on the file to krb5_keytab_t. Set the ownership on the keytab file to root.root and the permissions to 600. Apache should not have access. Update the path in the '/etc/gssproxy/00-http.conf' file to point to the new keytab location.

Instruct the user on how to create the necessary SPN in active directory, either from windows using the setspn command, or from Linux using the adcli command or via another method. Without this step, Kerberos authentication will fail.

Make it clear that the expected behavior of the browser is not to attempt Kerberos authentication when using the server FQDN unless the hostname has been included in the browser's defined "Local intranet" zone.

Additional information: