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:
- 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
- Navigate to
. - Click .
- On the 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
TLSencrypted connections, select the LDAPS check box to enable encryption. The port should change to 636, which is the default for LDAPS. - On the tab, enter the account information and domain name details. See Section 8.1.3, “LDAP Setting Descriptions and Examples” for descriptions and examples.
- On the 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.
- On the 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.
- On the 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.
- Click .
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 tab.
| 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.
| 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 |
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.
| 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 |
| 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 |
