Chapter 8. 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:
  • 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 8.1, “Using LDAP”. Though you can use LDAP to connect to an IdM or AD server, the setup does not support server discovery, cross-forest trusts, or single sign-on with Kerberos on Satellite's web UI.
  • Using Red Hat Enterprise Linux Identity Management (IdM) server as an external identity provider. IdM deals with the management of individual identities, their credentials and privileges used in a networking environment. For more information see Section 8.2, “Using Identity Management”.
  • Using Active Directory (AD) integrated with IdM through cross-forest Kerberos trust as an external identity provider. For more information see Section 8.3.1, “Using Active Directory with Cross-Forest Trust”.
  • Using direct AD as an external identity provider. For more information see Section 8.3.2, “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 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 8.5, “External Authentication for Provisioned Hosts” for more information.

8.1. Using LDAP

8.1.1. Configure TLS for Secure LDAP (LDAPS)

Note

Though direct LDAP integration is covered in this section, Red Hat recommends that you use SSSD and configure it against IdM, AD, or an LDAP server. These preferred configurations are explained elsewhere in this guide.
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 8.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.2 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

8.1.2. Configuring Red Hat Satellite to Use LDAP

Follow this procedure to configure LDAP authentication using the web UI. Note that if you need single sign-on functionality with Kerberos on Satellite's web UI, you should use IdM and AD external authentication instead. See Section 8.2, “Using Identity Management” or Section 8.3, “Using Active Directory” for more information on those options.

Procedure 8.1. To Configure LDAP Authentication:

  1. Set the allow Network Information System (NIS) service boolean to true to prevent SELinux from stopping outgoing LDAP connections:
    • For Red Hat Enterprise Linux 6: 
      # setsebool -P allow_ypbind on
    • For Red Hat Enterprise Linux 7: 
      # setsebool -P nis_enabled on
  2. Navigate to Administer → LDAP Authentication.
  3. Click New authentication source.
  4. 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.
  5. On the Account tab, enter the account information and domain name details. See Section 8.1.3, “LDAP Setting Descriptions and Examples” for descriptions and examples.
  6. On the Attribute mappings tab, map LDAP attributes to Satellite attributes. You can map Login name, First name, Surname, Email address, and Photo attributes. See Section 8.1.3, “LDAP Setting Descriptions and Examples” for examples.
  7. On the Locations tab, select locations from the left table. Selected locations will be assigned to users created from the LDAP authentication source, and available after their first login.
  8. On the Organizations tab, select organizations from the left table. Selected organizations will be assigned to users created from the LDAP authentication source, and available after their first login.
  9. Click Submit.
The Satellite Server is now configured to use the LDAP server. If you did not select Automatically create accounts in Satellite, see Section 4.1.1, “Creating a User” to create user accounts manually. If you selected the option, LDAP users can now log in to Satellite using their LDAP accounts and passwords. After they log in for the first time, Satellite administrator will need to assign roles manually. See Section 4.1.3, “Assigning Roles to a User” to assign user accounts appropriate roles in Satellite.

8.1.3. LDAP Setting Descriptions and Examples

The following table provides a description for each setting in the Account tab.

Table 8.1. Account Tab Settings

Setting Description
Account username The 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: 
uid=$login,cn=users,cn=accounts,dc=example,dc=com
The $login variable stores the username entered on the login page as a literal string. The value is accessed when the variable is expanded.
The variable cannot be used with external user groups from an LDAP source because Satellite needs to retrieve the group list without the user logging in. Use either an anonymous, or dedicated service user.
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 the LDAP directory.
Groups base DN
The top level domain name of the LDAP directory tree that contains groups.
LDAP filter
A filter to restrict LDAP queries.
Automatically create accounts in Satellite
If this option is selected, when LDAP users log in to Satellite for the first time, Satellite user accounts are created automatically for them. Users will see a Permissions Denied warning and need to contact their Satellite administrator to have their user account associated with roles.
Usergroup sync
If this option is selected, the user group membership of a user is automatically synchronized when the user logs in, which ensures the membership is always up to date. If this option is cleared, Satellite relies on a Cron job to regularly synchronize group membership (every 30 minutes by default). See Procedure 8.6, “To Configure an External User Group:” for further context.
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 8.2. Example Settings for Active Directory LDAP Connection

Setting Example value
Account username DOMAIN\redhat
Account password P@ssword
Base DN DC=example,DC=COM
Groups Base DN CN=Users,DC=example,DC=com
Login name attribute userPrincipalName
First name attribute givenName
Surname attribute sn
Email address attribute mail

Note

userPrincipalName allows the use of whitespace in usernames. The login name attribute sAMAccountName (which is not listed in the table above) provides backwards compatibility with legacy Microsoft systems. sAMAccountName does not allow the use of whitespace in usernames.

Table 8.3. Example Settings for FreeIPA or Red Hat Identity Management 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
First name attribute givenName
Surname attribute sn
Email address attribute mail

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

Setting Example value
Account username uid=redhat,ou=users,dc=example,dc=com
Base DN dc=example,dc=com
Groups Base DN cn=employee,ou=userclass,dc=example,dc=com
Login name attribute uid
First name attribute givenName
Surname attribute sn
Email address attribute mail