第13章 Configuring External Authentication
By using external authentication you can derive user and user group permissions from user group membership in an external identity provider. When you use external authentication, you do not have to create these users and maintain their group membership manually on Satellite Server.
Important User and Group Account Information
All user and group accounts must be local accounts. This is to ensure that there are no authentication conflicts between local accounts on your Satellite Server and accounts in your Active Directory domain.
Your system is not affected by this conflict if your user and group accounts exist in both /etc/passwd
and /etc/group
files. For example, to check if entries for puppet
, apache
, foreman
and foreman-proxy
groups exist in both /etc/passwd
and /etc/group
files, enter the following commands:
# cat /etc/passwd | grep 'puppet\|apache\|foreman\|foreman-proxy' # cat /etc/group | grep 'puppet\|apache\|foreman\|foreman-proxy'
Scenarios for Configuring External Authentication
Red Hat Satellite supports the following 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. With Satellite, you can manage LDAP entirely through the Satellite web UI. For more information, see 「Using LDAP」. Though you can use LDAP to connect to a Red Hat Identity Management or AD server, the setup does not support server discovery, cross-forest trusts, or single sign-on with Kerberos in Satellite’s web UI.
- Using a Red Hat Identity Management server as an external identity provider. Red Hat Identity Management deals with the management of individual identities, their credentials and privileges used in a networking environment. Configuration using Red Hat Identity Management cannot be completed using only the Satellite web UI and requires some interaction with the CLI. For more information see 「Using Red Hat Identity Management」.
- Using Active Directory (AD) integrated with Red Hat Identity Management through cross-forest Kerberos trust as an external identity provider. For more information see 「Active Directory with Cross-Forest Trust」.
- Using Red Hat Single Sign-On as an OpenID provider for external authentication to Satellite with CAC cards. For more information, see 「Integrating Satellite with Red Hat Single Sign-On for External Authentication」.
As well as providing access to Satellite Server, hosts provisioned with Satellite can also be integrated with Red Hat Identity Management realms. Red Hat Satellite has a realm feature that automatically manages the life cycle of any system registered to a realm or domain provider. For more information, see 「External Authentication for Provisioned Hosts」.
表13.1 Authentication Overview
Type | Authentication | User Groups |
---|---|---|
Red Hat Identity Management | Kerberos or LDAP | Yes |
Active Directory | Kerberos or LDAP | Yes |
POSIX | LDAP | Yes |
13.1. Using LDAP
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 「Configuring Red Hat Satellite to use LDAP」.
Using SSSD Configuration
Though direct LDAP integration is covered in this section, Red Hat recommends that you use SSSD and configure it against Red Hat Identity Management, AD, or an LDAP server. SSSD improves the consistency of the authentication process. For more information about the preferred configurations, see 「Using Active Directory」. You can also cache the SSSD credentials and use them for LDAP authentication. For more information on SSSD, see Configuring SSSD in the Red Hat Enterprise Linux 7 System-Level Authentication Guide.
13.1.1. Configuring TLS for Secure LDAP
Use the Satellite CLI to configure TLS for secure LDAP (LDAPS).
Procedure
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 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.
-
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
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:# systemctl restart httpd
13.1.2. Configuring Red Hat Satellite to use LDAP
In the Satellite web UI, configure Satellite to use LDAP.
Note that if you need single sign-on functionality with Kerberos on Satellite’s web UI, you should use Red Hat Identity Management and AD external authentication instead. See Using Red Hat Identity Management or Using Active Directory for more information on those options.
Procedure
Set the Network Information System (NIS) service boolean to true to prevent SELinux from stopping outgoing LDAP connections:
# setsebool -P nis_enabled on
- Navigate to Administer > LDAP Authentication.
- Click Create Authentication Source.
-
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. - On the Account tab, enter the account information and domain name details. See 「Description of LDAP Settings」 for descriptions and examples.
- On the Attribute mappings tab, map LDAP attributes to Satellite attributes. You can map login name, first name, last name, email address, and photo attributes. See 「Example Settings for LDAP Connections」 for examples.
- On the Locations tab, select locations from the left table. Selected locations are assigned to users created from the LDAP authentication source, and available after their first login.
- On the Organizations tab, select organizations from the left table. Selected organizations are assigned to users created from the LDAP authentication source, and available after their first login.
- Click Submit.
Configure new accounts for LDAP users:
- If you did not select Automatically Create Accounts In Satellite check box, see 「Creating a User」 to create user accounts manually.
- If you selected the Automatically Create Accounts In Satellite check box, LDAP users can now log in to Satellite using their LDAP accounts and passwords. After they log in for the first time, the Satellite administrator has to assign roles to them manually. See 「Assigning Roles to a User」 to assign user accounts appropriate roles in Satellite.
13.1.3. Description of LDAP Settings
The following table provides a description for each setting in the Account tab.
表13.2 Account Tab Settings
Setting | Description |
---|---|
Account | The user name of the LDAP account that 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 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 |
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 check box is selected, Satellite creates user accounts for LDAP users when they log in to Satellite for the first time. After they log in for the first time, the Satellite administrator has to assign roles to them manually. See 「Assigning Roles to a User」 to assign user accounts appropriate roles in Satellite. |
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 To Configure an External User Group: for further context. |
13.1.4. Example Settings for LDAP Connections
The following table shows example settings for different types of LDAP connections. The example below uses 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.
表13.3 Example Settings for Active Directory, Free IPA or Red Hat Identity Management and POSIX LDAP Connections
Setting | Active Directory | FreeIPA or Red Hat Identity Management | POSIX (OpenLDAP) |
---|---|---|---|
Account | DOMAIN\redhat | uid=redhat,cn=users, cn=accounts,dc=example, dc=com | uid=redhat,ou=users, dc=example,dc=com |
Account password | P@ssword | - | - |
Base DN | DC=example,DC=COM | dc=example,dc=com | dc=example,dc=com |
Groups Base DN | CN=Users,DC=example,DC=com | cn=groups,cn=accounts, dc=example,dc=com | cn=employee,ou=userclass, dc=example,dc=com |
Login name attribute | userPrincipalName | uid | uid |
First name attribute | givenName | givenName | givenName |
Last name attribute | sn | sn | sn |
Email address attribute | | | |
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.
13.1.5. Example LDAP Filters
As an administrator, you can create LDAP filters to restrict the access of specific users to Satellite.
表13.4 Example filters for allowing specific users to login
User | Filter |
---|---|
User1, User3 | (memberOf=cn=Group1,cn=Users,dc=domain,dc=example) |
User2, User3 | (memberOf=cn=Group2,cn=Users,dc=domain,dc=example) |
User1, User2, User3 | (|(memberOf=cn=Group1,cn=Users,dc=domain,dc=example)(memberOf=cn=Group2,cn=Users,dc=domain,dc=example)) |
LDAP directory structure
The LDAP directory structure that the filters in the example use:
DC=Domain,DC=Example | |----- CN=Users | |----- CN=Group1 |----- CN=Group2 |----- CN=User1 |----- CN=User2 |----- CN=User3
LDAP group membership
The group membership that the filters in the example use:
Group | Members |
---|---|
Group1 | User1, User3 |
Group2 | User2, User3 |