Chapter 11. 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 11.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 11.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 11.3.1, “Using Active Directory with Cross-Forest Trust”.
  • Using direct AD as an external identity provider. For more information see Section 11.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 automatically manages the life cycle of any system registered to a realm or domain provider. See Section 11.5, “External Authentication for Provisioned Hosts” for more information.

11.1. Using LDAP

11.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 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.3 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

11.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 Using Identity Management or Using Active Directory for more information on those options.

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 11.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 11.1.3, “LDAP Setting Descriptions and Examples” for examples.
  7. 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.
  8. 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.
  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 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, the Satellite administrator(s) have to assign roles manually. See Assigning Roles to a User to assign user accounts appropriate roles in Satellite.

11.1.3. LDAP Setting Descriptions and Examples

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

Table 11.1. Account Tab Settings

SettingDescription

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. See Section 11.1.3.1, “Example LDAP Filters” for examples.

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 may see a Permissions Denied warning. These users have to contact their Satellite administrator to request that suitable roles are associated with their accounts.

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.

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 11.2. Example Settings for Active Directory LDAP Connection

SettingExample 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 11.3. Example Settings for FreeIPA or Red Hat Identity Management LDAP Connection

SettingExample 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 11.4. Example Settings for POSIX (OpenLDAP) LDAP Connection

SettingExample 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

11.1.3.1. Example LDAP Filters

As an administrator, you can create LDAP filters to restrict the access of specific users to Satellite.

Table 11.5. Example filters for allowing specific users to login

UserFilter

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

(&(objectClass=user)((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:

GroupMembers

Group1

User1, User3

Group2

User2, User3

11.2. Using Identity Management

Select from one of the following methods:

11.2.1. Using Identity Management Directly

This section shows how to integrate Red Hat Satellite Server with an IdM server and how to enable host-based access control.

Prerequisites

The Satellite Server has to run on Red Hat Enterprise Linux 7.1 or Red Hat Enterprise Linux 6.6 or later.

The examples in this chapter assume separation between IdM and Satellite configuration. However, if you have administrator privileges for both servers, you can configure IdM as described in Red Hat Enterprise Linux 7 Linux Domain Identity, Authentication, and Policy Guide[2].

The base operating system of the Satellite Server must be enrolled in the IdM domain by the IdM administrator of your organization.

To Configure IdM Authentication on the Satellite Server:

  1. On the IdM server, create a host entry for the Satellite Server and generate a one-time password, for example:

    # ipa host-add --random hostname
    Note

    The generated one-time password must be used on the client to complete IdM-enrollment.

    For more information on host configuration properties, see Red Hat Enterprise Linux 7 Linux Domain Identity, Authentication, and Policy Guide[3].

  2. Create an HTTP service for the Satellite Server, for example:

    # ipa service-add servicename/hostname

    For more information on managing services, see Red Hat Enterprise Linux 7 Linux Domain Identity, Authentication, and Policy Guide[4].

  3. On the Satellite Server, execute the following command as root to configure IdM-enrollment:

    # ipa-client-install --password OTP

    Replace OTP with the one-time password provided by the IdM administrator.

  4. If the Satellite Server is running on Red Hat Enterprise Linux 7, execute the following command:

    # subscription-manager repos --enable rhel-7-server-optional-rpms

    The installer is dependent on packages which, on Red Hat Enterprise Linux 7, are in the optional repository rhel-7-server-optional-rpms. On Red Hat Enterprise Linux 6 all necessary packages are in the base repository.

  5. Execute the following command:

    # satellite-installer --foreman-ipa-authentication=true

    This command is not limited to a fresh Satellite installation; you can use it to modify an existing Satellite installation.

  6. Restart Katello services:

    # katello-service restart

External users can now log in to Satellite using their IdM credentials. They can now choose to either log in to the Satellite Server directly using their username and password or take advantage of the configured Kerberos single sign on and obtain a ticket on their client machine and be logged in automatically. The two-factor authentication with one-time password (2FA OTP) is also supported. If the user in IdM is configured for 2FA, and the Satellite Server is running on Red Hat Enterprise Linux 7, this user can also authenticate to Satellite with a OTP. Optionally proceed to the next procedure to confgiure host-based access control (HBAC).

HBAC rules define which machine within the domain an IdM user is allowed to access. You can configure HBAC on the IdM server to prevent selected users from accessing the Satellite Server. With this approach, you can prevent Satellite from creating database entries for users that are not allowed to log in. For more information on HBAC, see the Red Hat Enterprise Linux 7 Linux Domain Identity, Authentication, and Policy Guide[5].

To Configure HBAC:

  1. Create HBAC service and rule on the IdM server and link them together. The following examples use the PAM service name satellite-prod. Execute the following commands on the IdM server:

    $ ipa hbacsvc-add satellite-prod
    $ ipa hbacrule-add allow_satellite_prod
    $ ipa hbacrule-add-service allow_satellite_prod --hbacsvcs=satellite-prod
  2. Add the user who is to have access to the service satellite-prod, and the host name of the Satellite Server:

    $ ipa hbacrule-add-user allow_satellite_prod --user=username
    $ ipa hbacrule-add-host allow_satellite_prod --hosts=the-satellite-fqdn

    Alternatively, host groups and user groups can be added to the allow_satellite_prod rule.

  3. To check the status of the rule, execute:

    $ ipa hbacrule-find satellite-prod
    $ ipa hbactest --user=username --host=the-satellite-fqdn --service=satellite-prod
  4. Ensure the allow_all rule is disabled on the IdM server. For instructions on how to do so without disrupting other services see the How to configure HBAC rules in IdM article on the Red Hat Customer Portal [6].
  5. Configure the IdM integration with the Satellite Server as described in To Configure IdM Authentication on the Satellite Server:. On the Satellite Server, define the PAM service as root:

    # satellite-installer --foreman-pam-service=satellite-prod

11.2.2. Using Identity Management with LDAP Authentication

To attach Identity Management as an external authentication source with no single sign-on support, see Section 11.1, “Using LDAP” for more information.

11.3. Using Active Directory

Select from one of the following methods:

11.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[7].

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 11.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

11.3.2. Using Active Directory Directly

This section shows how to use direct Active Directory (AD) as an external authentication source for Satellite Server. Direct AD integration means that 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 To Enroll Satellite Server with the AD Server, then finalize the AD integration with use of GSS-proxy as described in 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 Red Hat Satellite Server to be deployed on Red Hat Enterprise Linux 7.1 or later.

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

To Enroll Satellite Server with the AD Server:

  1. Install the required packages:

    # yum install sssd adcli realmd ipa-python-compat krb5-workstation
  2. Enroll 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 a previously installed Satellite or during 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.

To Configure Direct AD Integration with GSS-proxy:

  1. Create the /etc/ipa/ directory and the default.conf file:

    # mkdir /etc/ipa
    # touch /etc/ipa/default.conf
  2. To the default.conf file, add the following content:

    [global]
    server = unused
    realm = EXAMPLE.ORG
  3. Create the /etc/net-keytab.conf file with the following content:

    [global]
    workgroup = EXAMPLE
    realm = EXAMPLE.ORG
    kerberos method = system keytab
    security = ads
  4. 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
  5. Insert the following line at the beginning of the /etc/krb5.conf file:

    includedir /var/lib/sss/pubconf/krb5.include.d/
  6. Create a keytab entry:

    # KRB5_KTNAME=FILE:/etc/httpd/conf/http.keytab net ads keytab add HTTP -U administrator -d3 -s /etc/net-keytab.conf
    # chown root.apache /etc/httpd/conf/http.keytab
    # chmod 640 /etc/httpd/conf/http.keytab
  7. Enable IPA authenication in Satellite:

    # satellite-installer --foreman-ipa-authentication=true
  8. Start and enable the gssproxy service:

    # systemctl restart gssproxy.service
    # systemctl enable gssproxy.service
  9. Configure the Apache 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
  10. Start and enable the httpd service:

    # systemctl restart httpd.service

    With a running Apache server, users making HTTP requests against the server are authenticated if the client has a valid Kerberos ticket.

    To confirm that SSO is working as expected, on Satellite Server, enter the following command to retrieve the Kerberos ticket of the LDAP user:

    # kinit ldapuser

    To view the Kerberos ticket, enter the following command:

    # klist

    To view output from successful SSO-based authentication, enter the following command:

    # curl -k -u : --negotiate https://satellite.example.com/users/extlogin
    <html><body>You are being <a href="https://satellite.example.com/users/4-ldapuserexample-com/edit">redirected</a>.</body></html>

Users can now configure Kerberos SSO in their browsers to be able to log in without filling in access credentials in the Satellite UI. For more information on configuring the Firefox browser see the Red Hat Enterprise Linux System-Level Authentication Guide. If you use the Internet Explorer browser, add 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[8].

11.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 11.1, “Using LDAP” for more information. For an example configuration, see How to configure Active Directory authentication with TLS on Satellite 6.

11.4. Configuring External User Groups

Users authenticated through external sources are automatically created on the Satellite Server the first time they log in. This does not apply to external user groups that must be mapped to user groups created manually in the Satellite GUI. Members of the external user group then automatically become members of the Satellite user group and receive the associated permissions.

Prerequisites

The configuration of external user groups depends on the type of external authentication:

  • If using an LDAP source, make sure the LDAP authentication is correctly configured. Navigate to Administer > LDAP Authentication to view and modify the existing sources. For instructions on how to create an LDAP source, see Section 11.1, “Using LDAP”. Take note of the LDAP group names you want to use.
Note

If you are using external user groups from an LDAP source, you cannot use the $login variable as a substitute for the account user name. You need to use either an anonymous or dedicated service user.

  • If your Satellite is enrolled with the IdM or AD server as described in Chapter 11, Configuring External Authentication, take note of the external group names you want to use. To find the group membership of external users, execute the id command on Satellite:

    # id username

    Here, username is the name of the external group member. Note that Satellite allows you to configure external groups only after at least one external user authenticates for the first time. Also, at least one user must exist in the external authentication source.

To Configure an External User Group:

  1. Navigate to Administer > User Groups. Click New User Group.
  2. On the User group tab, specify the name of the new user group. Do not select any users as they would be added automatically when refreshing the external user group.
  3. On the Roles tab, select the roles you want to assign to the user group. Alternatively, select the Administrator check box to assign all available permissions.
  4. On the External groups tab, click Add external user group and select an authentication source from the Auth source drop-down menu.

    Specify the exact name of the LDAP or external group in the Name field.

  5. Click Submit.
Important

You can set the LDAP source to synchronize user group membership automatically on user login. If this option is not set, LDAP user groups are refreshed automatically through a scheduled task (cron job) synchronizing the LDAP Authentication source (every 30 minutes by default). If the user groups in the LDAP Authentication source change in the lapse of time between scheduled tasks, the user can be assigned to incorrect external user groups. This is corrected automatically when the scheduled task runs. You can also refresh the LDAP source manually by executing foreman-rake ldap:refresh_usergroups or by refreshing the external user groups through the web UI.

External user groups based on IdM or AD are refreshed only when a group member logs in to Satellite. It is not possible to alter user membership of external user groups in the Satellite GUI, such changes are overwritten on the next group refresh. To assign additional permissions to an external user, add this user to an internal user group that has no external mapping specified. Then assign the required roles to this group.

11.5. External Authentication for Provisioned Hosts

This section shows how to configure IdM integration to authenticate provisioned hosts. First configure the Satellite or Capsule Server for IdM realm support, then add hosts to the IdM realm group.

11.5.1. Configuring a Red Hat Satellite Server or Capsule Server for IdM Realm Support

To use IdM for provisioned hosts, first configure the Red Hat Satellite Server or Red Hat Satellite Capsule Server.

Prerequisites

  • A Satellite Server is registered to the content delivery network, an independent Capsule Server is registered to the Satellite Server.
  • A realm or domain provider such as Red Hat Identity Management is configured.

To configure the Satellite Server or Capsule Server for IdM Realm Support:

  1. On the Satellite Server or Capsule Server, install the following packages:

    # yum install ipa-client foreman-proxy ipa-admintools
  2. Configure the Satellite Server (or Capsule Server) as an IdM client:

    # ipa-client-install
  3. Create a realm-capsule user and the relevant roles in Red Hat Identity Management on the Satellite Server or Capsule Server:

    # foreman-prepare-realm admin realm-capsule

    Running foreman-prepare-realm prepares an IdM server for use with the Capsule Server. It creates a dedicated role with the permissions needed for Satellite, creates a user with that role and retrieves the keytab file. You require your Identity Management server configuration details for this step.

    If the command successfully executes, you should be able to see the following command output:

    Keytab successfully retrieved and stored in: freeipa.keytab
    Realm Proxy User:    realm-capsule
    Realm Proxy Keytab:  /root/freeipa.keytab
    Note

    To configure Satellite Server and at least one external Capsule Server for IdM Realm support with the same principal and realm, you must copy the /root/freeipa.keytab file to all the previously joined Capsule Servers after running the foreman-prepare-realm script.

    # scp /root/freeipa.keytab your_username@capsule.example.com:/etc/foreman-proxy/freeipa.keytab
  4. Move the /root/freeipa.keytab to the /etc/foreman-proxy directory and set the ownership settings to the user foreman-proxy:

    # mv /root/freeipa.keytab /etc/foreman-proxy
    # chown foreman-proxy:foreman-proxy /etc/foreman-proxy/freeipa.keytab
  5. Configure the realm based on whether you are using Satellite Server or Capsule Server:

    • If you are using the integrated Capsule Server in the Satellite Server, use satellite-installer to configure the realm:

      # satellite-installer --foreman-proxy-realm true \
      --foreman-proxy-realm-keytab /etc/foreman-proxy/freeipa.keytab \
      --foreman-proxy-realm-principal realm-capsule@EXAMPLE.COM \
      --foreman-proxy-realm-provider freeipa
      Note

      You can also run these options when you first configure the Red Hat Satellite Server.

    • If you are using an external Capsule Server, use satellite-installer --scenario capsule to configure the realm:

      # satellite-installer --scenario capsule \
      --foreman-proxy-realm true \
      --foreman-proxy-realm-keytab /etc/foreman-proxy/freeipa.keytab \
      --foreman-proxy-realm-principal realm-capsule@EXAMPLE.COM \
      --foreman-proxy-realm-provider freeipa
  6. Make sure that the most updated versions of the ca-certificates package is installed and trust the IdM Certificate Authority:

    # cp /etc/ipa/ca.crt /etc/pki/ca-trust/source/anchors/ipa.crt
    # update-ca-trust enable
    # update-ca-trust
  7. (Optional) If you are configuring IdM on an already existing Satellite Server or Capsule Server, the following steps should also be taken to make sure that the configuration changes take effect:

    1. Restart the foreman-proxy service:

      # service foreman-proxy restart
    2. Log in to the Satellite Server and click Infrastructure > Capsules.
    3. Click on the drop-down menu on the right-hand side of the Capsule Server you have configured for IdM and choose Refresh Features.
  8. Finally, create a new realm entry in the Satellite Server user interface:

    1. Click Infrastructure > Realms and on the right-hand corner of the main page, click New Realm.
    2. Fill in the fields in the following subtabs:

      • On the Realm subtab, provide the realm name, the type of realm to use and the realm proxy.
      • On the Locations subtab, choose the locations where the new realm is intended for use.
      • On the Organizations subtab, choose the organizations where the new realm is intended for use.
    3. Click Submit.

The Satellite Server or Capsule Server is now ready to provision hosts that automatically register to IdM. The next section details the steps on how to automatically add hosts to an IdM host group.

11.5.2. Adding Hosts to an IdM Host Group

Red Hat Enterprise Linux Identity Management (IdM) supports the ability to set up automatic membership rules based on a system’s attributes. Red Hat Satellite’s realm feature provides administrators with the ability to map the Red Hat Satellite host groups to the IdM parameter "userclass" which allow administrators to configure automembership.

When nested host groups are used, they are sent to the IdM server as they are displayed in the Red Hat Satellite User Interface. For example, "Parent/Child/Child".

Note

The Satellite Server or Capsule Server sends updates to the IdM server, however automembership rules are only applied at initial registration.

To Add Hosts to an IdM Host Group:

  1. On the IdM server, create a host group:

    # ipa hostgroup-add hostgroup_name
    Description: hostgroup_description
    ----------------------------
    Added hostgroup "hostgroup_name"
    ----------------------------
    Host-group: hostgroup_name
    Description: hostgroup_description

    Where:

    • hostgroup_name is the host group’s name.
    • hostgroup_description is the host group’s description.
  2. Create an automembership rule:

    # ipa automember-add --type=hostgroup automember_rule
    ----------------------------------
    Added automember rule "automember_rule"
    ----------------------------------
    Automember Rule: automember_rule

    Where:

    • automember-add flags the group as an automember group.
    • --type=hostgroup identifies that the target group is a host group, not a user group.
    • automember_rule is the name you wish to identify the automember rule by.
  3. Define an automembership condition based on the userclass attribute:

    # ipa automember-add-condition --key=userclass --type=hostgroup --inclusive-regex=^webserver hostgroup_name
    ----------------------------------
    Added condition(s) to "hostgroup_name"
    ----------------------------------
    Automember Rule: automember_rule
    Inclusive Regex: userclass=^webserver
    ----------------------------
    Number of conditions added 1
    ----------------------------

    Where:

    • automember-add-condition allows you to add regular expression conditions to identify group members.
    • --key=userclass specifies the key attribute as userclass.
    • --type=hostgroup identifies that the target group is a host group, not a user group.
    • --inclusive-regex= ^webserver is a regular expression pattern to identify matching values.
    • hostgroup_name is the target host group’s name.

When a system is added to the Satellite Server’s hostgroup_name host group, it is automatically added to the Identity Management server’s "hostgroup_name" host group. IdM host groups allow for Host-Based Access Controls (HBAC), sudo policies and other IdM functions.