Chapter 20. Configuring External Authentication

By using external authentication you can derive user and user group permissions from user group membership in an external identity provider. Therefore, you do not have to create these users and maintain their group membership manually on the Satellite server. Red Hat Satellite supports four general scenarios for configuring external authentication:
  1. Using Lightweight Directory Access Protocol (LDAP) server as an external identity provider. LDAP is a set of open protocols used to access centrally stored information over a network. For more information see Section 20.1, “Using LDAP”.
  2. Using Identity Management (IdM) or Identity, Policy, Audit (IPA) server as an external identity provider. IdM and IPA deal with the management of individual identities, their credentials and privileges used in a networking environment. For more information see Section 20.2, “Using Identity Management”.
  3. Using Active Directory (AD) integrated with IdM or IPA through cross-forest Kerberos trust as an external identity provider. For more information see Section 20.3, “Using Active Directory with Cross-Forest Trust”.
  4. Using direct AD as an external identity provider. For more information see Section 20.4, “Using Active Directory Directly”.
The above scenarios are about providing access to the Satellite server. In addition, hosts provisioned with Satellite can also be integrated with IdM/IPA realms. Red Hat Satellite has a realm feature that will automatically manage the life cycle of any system registered to a realm or domain provider. See Section 20.5, “External Authentication for Provisioned Hosts” for more information.

20.1. Using LDAP

Red Hat Satellite includes the option to use a Lightweight Directory Access Protocol (LDAP) service for user information and authentication, using one or more LDAP directories. See Red Hat Enterprise Linux System Administrator's Guide[8] for more information on LDAP.
You can also use LDAP to connect to an IdM/IPA or AD server, however this is not recommended as LDAP does not support server discovery or cross-forest trusts.

20.1.1. Configure TLS for Secure LDAP (LDAPS)

If you require Red Hat Satellite to use TLS to establish a secure LDAP connection (LDAPS), first obtain certificates used by the LDAP server you are connecting to and mark them as trusted on the base operating system of your Satellite server as described below. If your LDAP server uses a certificate chain with intermediate certificate authorities, all of the root and intermediate certificates in the chain must be trusted, so ensure all certificates are obtained. If you do not require secure LDAP at this time, proceed to Procedure 20.1, “To Configure LDAP Authentication”.

Obtain the Certificate from the LDAP Server

If you use Active Directory Certificate Services, export the Enterprise PKI CA Certificate using the Base-64 encoded X.509 format. See How to configure Active Directory authentication with TLS on Satellite 6.1 for information on creating and exporting a CA certificate from an Active Directory server.
Download the LDAP server certificate to a temporary location on the Red Hat Enterprise Linux system where the Satellite server is installed and remove it when finished. For example, /tmp/example.crt. The filename extensions .cer and .crt are only conventions and can refer to DER binary or PEM ASCII format certificates.

Trust the Certificate from the LDAP Server

Red Hat Satellite Server requires the CA certificates for LDAP authentication to be individual files in /etc/pki/tls/certs/ directory.
Use the install command to install the imported certificate into the /etc/pki/tls/certs/ directory with the correct permissions.
# install /tmp/example.crt /etc/pki/tls/certs/
Enter the following command as root to trust the example.crt certificate obtained from the LDAP server:
# ln -s example.crt /etc/pki/tls/certs/$(openssl x509 -noout -hash -in /etc/pki/tls/certs/example.crt).0
Restart the httpd service:
  • On Red Hat Enterprise Linux 6:
    # service httpd restart
  • On Red Hat Enterprise Linux 7:
    # systemctl restart httpd

20.1.2. Configuring Red Hat Satellite to Use LDAP


SELinux can prevent outgoing LDAP connections. Execute the following command to allow them:
# setsebool authlogin_nsswitch_use_ldap=1

Procedure 20.1. To Configure LDAP Authentication

Follow this procedure to configure LDAP authentication using the web UI. See the tables below this procedure for examples of the parameter format relevant to the LDAP server being used.
  1. Navigate to AdministerLDAP Authentication.
  2. Click New authentication source.
  3. On the LDAP server tab, enter the LDAP server's name, host name, port, and server type. The default port is 389, the default server type is POSIX (alternatively you can select FreeIPA or Active Directory depending on the type of authentication server). For TLS encrypted connections, select the LDAPS check box to enable encryption. The port should change to 636, which is the default for LDAPS.
  4. On the Account tab, enter the following information:
    • Account username: an LDAP user who has read access to the LDAP server. User name is not required if the server allows anonymous reading, otherwise use the full path to the user's object. For example:
    • Account password: the LDAP password for the user defined in the Account username field. This field can remain blank if the Account username is using the "$login" variable.
    • Base DN: the top level domain name of your LDAP directory. For example:
    • Groups base DN: the top level domain name of your LDAP directory tree that contains groups.
    • LDAP filter: a filter to restrict your LDAP queries.
    • Automatically create accounts in Foreman: creates Satellite accounts automatically for LDAP users who log in for the first time in Satellite.
  5. On the Attribute mappings tab, map LDAP attributes to Satellite attributes. You can map Login name, First name, Surname, Email address, and Photo attributes.
  6. Click Submit.
The following tables show example settings for different types of LDAP connections. All of the examples below use a dedicated service account called redhat that has bind, read, and search permissions on the user and group entries. Note that LDAP attribute names are case sensitive.

Table 20.1. Example Settings for Active Directory LDAP Connection

Setting Example value
Account username DOMAIN\redhat
Base DN DC=example,DC=COM
Groups Base DN CN=Users,DC=example,DC=com
Login name attribute sAMAccountName

Table 20.2. Example settings for FreeIPA LDAP Connection

Setting Example value
Account username uid=redhat,cn=users,cn=accounts,dc=example,dc=com
Base DN dc=example,dc=com
Groups Base DN cn=groups,cn=accounts,dc=example,dc=com
Login name attribute uid

Table 20.3. Example Settings for POSIX (OpenLDAP) LDAP Connection

Setting Example value
Account username uid=redhat,dc=example,dc=com
Base DN dc=example,dc=com
Groups Base DN dc=example,dc=com
Login name attribute uid