Red Hat Training

A Red Hat training course is available for Red Hat Satellite

8.3. Using Active Directory

Select from one of the following methods:

8.3.1. Using Active Directory with Cross-Forest Trust

Kerberos can create cross-forest trust that defines a relationship between two otherwise separate domain forests. A domain forest is a hierarchical structure of domains; both AD and IdM constitute a forest. With a trust relationship enabled between AD and IdM, users of AD can access Linux hosts and services using a single set of credentials. For more information on cross-forest trusts, see Red Hat Enterprise Linux Windows Integration Guide[9].
From the Satellite point of view, the configuration process is the same as integration with IdM server without cross-forest trust configured. The Satellite Server has to be enrolled in the IPM domain and integrated as described in Section 8.2, “Using Identity Management”. On the IdM server, the following additional steps are required:
  1. To enable the HBAC feature, create an external group and add the AD group to it. Add the new external group to a POSIX group. Use this POSIX group in a HBAC rule.
  2. Configure sssd to transfer additional attributes of AD users. Add these attributes to the nss and domain sections in /etc/sssd/sssd.conf. For example: 
    [nss]
user_attributes=+mail, +sn, +givenname

[domain/EXAMPLE]
ldap_user_extra_attrs=mail, sn, givenname

8.3.2. 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 8.4, “To Enroll the Satellite Server with the AD Server:”, then finalize the AD integration with use of GSS-proxy as described in Procedure 8.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 file 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 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. By completing the procedures, users that belong to the EXAMPLE.ORG realm can log in to the Satellite Server.

Prerequisites

Ensure that GSS-proxy and nfs-utils are installed: 
# yum install gssproxy nfs-utils

Procedure 8.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 satellite-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 8.5. To Configure Direct AD Integration with GSS-proxy:

  1. Create 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 the /etc/gssproxy/00-http.conf file with the following content: 
    [service/HTTP]
mechs = krb5
cred_store = keytab:/etc/krb5.keytab
cred_store = ccache:/var/lib/gssproxy/clients/krb5cc_%U
euid = 48
  4. Insert the following line at the beginning of the /etc/krb5.conf file: 
    includedir /var/lib/sss/pubconf/krb5.include.d/
  5. Enable IPA authentication in Satellite: 
    # satellite-installer --foreman-ipa-authentication=true
  6. Start and enable the gssproxy service: 
    # systemctl restart gssproxy.service
# systemctl enable gssproxy.service
  7. Configure Apache HTTPD Server to use the gssproxy service:
    1. Create the /etc/systemd/system/httpd.service file with the following content: 
      .include /lib/systemd/system/httpd.service
  [Service]
  Environment=GSS_USE_PROXY=1
    2. Apply changes to the service: 
      # systemctl daemon-reload
  8. Start and enable the httpd service: 
    # systemctl restart httpd.service
    With a running Apache HTTP Server, users making HTTP requests against the server are authenticated if the client has a valid Kerberos ticket.
Users can now 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 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 = +foreman
Here, foreman is the PAM service name. For more information on GPOs, please refer to the Red Hat Enterprise Linux Windows Integration Guide[10].

8.3.3. Using Active Directory with LDAP Authentication

To attach Active Directory as an external authentication source with no single sign-on support, see Section 8.1, “Using LDAP” for more information. For an example configuration, see How to configure Active Directory authentication with TLS on Satellite 6.