20.4. Using Active Directory Directly

This section shows how to use direct Active Directory (AD) as an external authentication source for the Satellite server. Direct AD integration means that the Satellite server is joined directly to the AD domain where the identity is stored. The recommended setup consists of two steps: first enroll Satellite with AD as described in Procedure 20.4, “To Enroll the Satellite Server with the AD Server:”, then finalize the AD integration with use of GSS-proxy as described in Procedure 20.5, “To Configure Direct AD Integration with GSS-proxy:”.
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 while preserving Kerberos authentication functionality. When using AD as an external authentication source for Satellite, it is recommended to implement GSS-proxy, because the keys in the http.keytab file are the same as the host keys.

Note

The AD integration requires the Red Hat Satellite server to be deployed on Red Hat Enterprise Linux 7.1.
Perform the following procedures on Red Hat Enterprise Linux that acts as a base operating system for your Satellite server. For the examples in this section EXAMPLE.ORG is the Kerberos realm for the AD domain.

Prerequisites

Ensure GSS-proxy is installed: 
# yum install gssproxy

Procedure 20.4. To Enroll the Satellite Server with the AD Server:

  1. Install the required packages: 
    # yum install sssd adcli realmd ipa-python
  2. Enroll the Satellite server with the AD server. You may need to have administrator permissions to perform the following command: 
    # realm join -v EXAMPLE.ORG
After enrolling Satellite with the AD server, you can configure the direct AD integration with GSS-proxy using the katello-installer command. This can be done for already installed Satellite or during the Satellite installation. Note that the Apache user must not have access to the keytab file. Also take note of the effective user ID of the Apache user (that can be found by executing id apache). The following procedure uses the example UID 48.

Procedure 20.5. To Configure Direct AD Integration with GSS-proxy:

  1. The katello-installer command is by default set for the IdM/IPA integration. Change this setting by creating the /etc/ipa/default.conf file with the following content: 
    [global]
   server = unused
   realm = EXAMPLE.ORG
  2. Create the /etc/net-keytab.conf file with the following content: 
    [global]
   workgroup = EXAMPLE
   realm = EXAMPLE.ORG
   kerberos method = system keytab
   security = ads
  3. Create a keytab file for HTTP using the following command: 
    # KRB5_KTNAME=FILE:/etc/gssproxy/http.keytab net ads keytab add HTTP -U administrator -d3 -s /etc/net-keytab.conf
    This command fetches the HTTP service keytab file from the AD server and stores it at /etc/gssproxy/http.keytab. Make sure this file is owned by the root user and group: 
    # chown root:root /etc/gssproxy/http.keytab
  4. Insert the following line at the beginning of the /etc/krb5.conf file: 
    includedir /var/lib/sss/pubconf/krb5.include.d/
  5. Create an empty keytab file at /etc/httpd/conf/http.keytab: 
    # touch /etc/httpd/conf/http.keytab
  6. Execute the following command: 
    # katello-installer --foreman-ipa-authentication=true
  7. Place the following text at the beginning of the /etc/gssproxy/gssproxy.conf configuration file: 
    [service/HTTP]
  mechs = krb5
  cred_store = keytab:/etc/gssproxy/http.keytab
  cred_store = ccache:/var/lib/gssproxy/clients/krb5cc_%U
  euid = 48
    Here, 48 is the effective UID of the Apache user. This text must precede any section containing the allow_any_uid=yes directive, therefore place it before the [service/nfs-client] section in the file.
  8. Create a separate cache directory for Kerberos to avoid AVC denials: 
    # mkdir /var/lib/gssproxy/rcache
    To configure the gssproxy service to use the cache, create the /etc/systemd/system/gssproxy.service file and insert the following text: 
    .include /usr/lib/systemd/system/gssproxy.service
[Service]
Environment=KRB5RCACHEDIR=/var/lib/gssproxy/rcache
    Apply changes to the service: 
    # systemctl daemon-reload
  9. Start and enable the gssproxy service: 
    # systemctl restart gssproxy.service
# systemctl enable gssproxy.service
  10. Configure the Apache server to use GSS-proxy by creating the /etc/systemd/system/httpd.service file with the following content: 
    .include /lib/systemd/system/httpd.service
[Service]
Environment=GSS_USE_PROXY=1
    Apply changes to the service: 
    # systemctl daemon-reload
  11. Start and enable the httpd service: 
    # systemctl restart httpd.service
    With a running Apache server, users making HTTP requests against the server are authenticated if the client has a valid Kerberos ticket.
By completing the above procedure you allow users that belong to the EXAMPLE.ORG realm to log in to the Satellite server. Users can configure Kerberos SSO in their browsers to be able to log in without filling in access credentials in the Satellite GUI. For more information on configuring the Firefox browser see the Red Hat Enterprise Linux System-Level Authentication Guide. Users of the Internet Explorer browser have to add the Satellite server to the list of Local Intranet or Trusted sites, and turn on the Enable Integrated Windows Authentication setting. See the Internet Explorer documentation for details.

Note

With direct AD integration, HBAC through IdM or IPA is not available. As an alternative, you can use Group Policy Objects (GPO) that enable administrators to centrally manage policies in AD environments. To ensure correct GPO to PAM service mapping, use the following sssd configuration: 
access_provider = ad
ad_gpo_access_control = enforcing
ad_gpo_map_service = +satellite-prod
Here, satellite-prod is the PAM service name. For more information on GPOs, please refer to the Red Hat Enterprise Linux Windows Integration Guide[15].