Configuring authentication for Red Hat Satellite users


Red Hat Satellite 6.17

Configure authentication for Satellite users and enable authentication features such as SSO, OTP, or 2FA

Red Hat Satellite Documentation Team

Abstract

You can connect your Satellite Server to an external authentication source to provide an additional layer of security for Satellite by enabling mechanisms such as single sign-on (SSO), one-time passwords (OTP), or two-factor authentication (2FA).

Providing feedback on Red Hat documentation

We appreciate your feedback on our documentation. Let us know how we can improve it.

Use the Create Issue form in Red Hat Jira to provide your feedback. The Jira issue is created in the Red Hat Satellite Jira project, where you can track its progress.

Prerequisites

Procedure

  1. Click the following link: Create Issue. If Jira displays a login error, log in and proceed after you are redirected to the form.
  2. Complete the Summary and Description fields. In the Description field, include the documentation URL, chapter or section number, and a detailed description of the issue. Do not modify any other fields in the form.
  3. Click Create.

Red Hat Satellite includes native support for authentication with a username and password. If you require additional methods of authentication, configure your Satellite Server to use an external authentication source.

Expand
Table 1.1. External authentication sources supported by Satellite and the authentication features they provide
 Username and passwordSingle sign-on (SSO)One-time password (OTP)Time-based one-time password (TOTP)Additional details

Active Directory (direct integration)

Yes

Yes

No

No

Chapter 6, Configuring Kerberos SSO for Active Directory users in Satellite

Identity Management

Yes (Linux and Active Directory users)

Yes (Linux users only)

No

No

Chapter 3, Configuring Kerberos SSO with Identity Management in Satellite

Red Hat Single Sign-On

Yes

Yes

Yes

Yes

Chapter 4, Configuring SSO and 2FA with Red Hat Single Sign-On in Satellite

LDAP

Yes

No

No

No

Chapter 7, Configuring an LDAP server as an external identity provider for Satellite

Chapter 2. Accessing Red Hat Satellite

After Red Hat Satellite has been installed and configured, use a browser to log in to the Satellite web UI interface. From the Satellite web UI, you can manage and monitor your Satellite infrastructure.

2.1. Logging in to the Satellite web UI

Use the web user interface to log in to Satellite for further configuration.

Prerequisites

Procedure

  1. Access Satellite Server using a web browser pointed to the fully qualified domain name:

    https://satellite.example.com/
    Copy to Clipboard Toggle word wrap
  2. Enter the user name and password created during the configuration process. If a user was not created during the configuration process, the default user name is admin.

Next steps

2.2. Importing the Katello root CA certificate

The first time you log in to Satellite, you might see a warning informing you that you are using the default self-signed certificate and you might not be able to connect this browser to Satellite until the root CA certificate is imported in the browser. Use the following procedure to locate the root CA certificate on Satellite and to import it into your browser.

To use the CLI instead of the Satellite web UI, see CLI procedure.

Prerequisites

  • Your Red Hat Satellite is installed and configured.

Procedure

  1. Identify the fully qualified domain name of your Satellite Server:

    # hostname -f
    Copy to Clipboard Toggle word wrap
  2. Access the pub directory on your Satellite Server using a web browser pointed to the fully qualified domain name:

    https://satellite.example.com/pub
    Copy to Clipboard Toggle word wrap
  3. When you access Satellite for the first time, an untrusted connection warning displays in your web browser. Accept the self-signed certificate and add the Satellite URL as a security exception to override the settings. This procedure might differ depending on the browser being used. Ensure that the Satellite URL is valid before you accept the security exception.
  4. Select katello-server-ca.crt.
  5. Import the certificate into your browser as a certificate authority and trust it to identify websites.

CLI procedure

  1. From the Satellite CLI, copy the katello-server-ca.crt file to the machine you use to access the Satellite web UI:

    # scp /var/www/html/pub/katello-server-ca.crt username@hostname:remotefile
    Copy to Clipboard Toggle word wrap
  2. In the browser, import the katello-server-ca.crt certificate as a certificate authority and trust it to identify websites.

2.3. Resetting the administrative user password

Use the following procedures to reset the administrative password to randomly generated characters or to set a new administrative password.

To reset the administrative user password

  1. Log in to the base operating system where Satellite Server is installed.
  2. Enter the following command to reset the password:

    # foreman-rake permissions:reset
    Reset to user: admin, password: qwJxBptxb7Gfcjj5
    Copy to Clipboard Toggle word wrap
  3. Use this password to reset the password in the Satellite web UI.
  4. Edit the ~/.hammer/cli.modules.d/foreman.yml file on Satellite Server to add the new password:

    # vi ~/.hammer/cli.modules.d/foreman.yml
    Copy to Clipboard Toggle word wrap

Unless you update the ~/.hammer/cli.modules.d/foreman.yml file, you cannot use the new password with Hammer CLI.

To set a new administrative user password

  1. Log in to the base operating system where Satellite Server is installed.
  2. To set the password, enter the following command:

    # foreman-rake permissions:reset password=new_password
    Copy to Clipboard Toggle word wrap
  3. Edit the ~/.hammer/cli.modules.d/foreman.yml file on Satellite Server to add the new password:

    # vi ~/.hammer/cli.modules.d/foreman.yml
    Copy to Clipboard Toggle word wrap

Unless you update the ~/.hammer/cli.modules.d/foreman.yml file, you cannot use the new password with Hammer CLI.

You can change the default text on the login page to a custom message you want your users to see every time they access the page. For example, your custom message might be a warning required by your company.

Procedure

  1. In the Satellite web UI, navigate to Administer > Settings, and click the General tab.
  2. Enter your custom message in the Login page footer text field.
  3. Click Submit.

Verification

  • Log out of the Satellite web UI and verify that the custom message is now displayed on the login page.

Identity Management is an open-source identity management solution that provides centralized authentication, authorization, and account management services. With Satellite, you can integrate Satellite Server with your existing Identity Management server to enable Identity Management users to authenticate to Satellite.

With your Identity Management server configured as an external identity provider, users defined in Identity Management can log in to Satellite with their Identity Management credentials. If cross-forest trust is configured between Identity Management and Active Directory, Active Directory users can also log in to Satellite.

Identity Management users can log in using the following methods:

  • Username and password
  • Kerberos single sign-on

When cross-forest trust is configured between Identity Management and Active Directory, Active Directory users can log in to Satellite with their user principal name (UPN) and password.

For information about Identity Management, including its cross-forest trust functionality, see Red Hat Enterprise Linux 9 Planning Identity Management and Red Hat Enterprise Linux 9 Installing Identity Management.

Create a host entry for your Satellite Server system in the Identity Management LDAP and configure the system to be a client in your Identity Management domain.

Prerequisites

  • An existing Identity Management server
  • Identity Management user account with privileges to enroll new Identity Management hosts

Procedure

  1. On the Identity Management server:

    1. Create a host entry for the Satellite Server system.

      For more information, see Red Hat Enterprise Linux 9 Managing IdM users, groups, hosts, and access control rules.

    2. Create an entry for the HTTP service for Satellite Server. This enables access to the keytab file by creating a service principal for your Satellite Server.

      For more information on creating a service entry in Identity Management, see Red Hat Enterprise Linux 9 Managing IdM users, groups, hosts, and access control rules.

  2. On your Satellite Server, configure the system as client in the Identity Management domain. This includes ensuring that the system meets the necessary prerequisites, installing the necessary packages, and running the ipa-client-install utility.

    For more information, see Red Hat Enterprise Linux 9 Installing Identity Management.

    Note

    To install packages on your Satellite Server, use the satellite-installer utility.

Verification

  • On your Satellite Server, check that you are able to resolve a user defined on the Identity Management server. For example, to check the admin user that Identity Management creates by default:

    $ id admin
    Copy to Clipboard Toggle word wrap

Example 3.1. Enrolling a Satellite Server system as a Identity Management client from the command line by using a one-time password

On the Identity Management server, a user named admin who has administrative privileges on the Identity Management server prepares a host entry for the Satellite Server system:

  1. Authenticate as the Identity Management admin user:

    # kinit admin
    Copy to Clipboard Toggle word wrap
  2. Optional: Verify that you have authenticated successfully:

    # klist
    Copy to Clipboard Toggle word wrap
  3. Create a host entry from the command line. Specify that you want to use a random password for the enrollment.

    # ipa host-add --random satellite-server.example.com
    --------------------------------------------------
     Added host "satellite-server.example.com"
     --------------------------------------------------
      Host name: satellite-server.example.com
      Random password: W5YpARl=7M.n
      Password: True
      Keytab: False
      Managed by: idm-server.example.com
    Copy to Clipboard Toggle word wrap
  4. Enable access to the keytab file by creating a service principal for your Satellite Server:

    # ipa service-add HTTP/satellite-server.example.com
    Copy to Clipboard Toggle word wrap

On the Satellite Server system, a user with Satellite administrative privileges enrolls the system into the Identity Management domain:

  1. Install the Identity Management client packages:

    # satellite-maintain packages install ipa-client
    Copy to Clipboard Toggle word wrap
  2. Configure the Satellite Server system a client in Identity Management by using the random password produced by ipa host-add in a previous step:

    # ipa-client-install --password 'W5YpARl=7M.n'
    Copy to Clipboard Toggle word wrap
  3. Verify that you are able to resolve the Identity Management admin user from your Satellite Server:

    $ id admin
    Copy to Clipboard Toggle word wrap

Enable Identity Management users to access Satellite by configuring Identity Management as an authentication provider on your Satellite Server.

Prerequisites

  • Satellite Server running on a system that is enrolled in the Identity Management domain.

Procedure

  1. Enable access for your preferred login method:

    • To enable access to the Satellite web UI only:

      # satellite-installer \
      --foreman-ipa-authentication true
      Copy to Clipboard Toggle word wrap
    • To enable access to the Satellite web UI and the Satellite API, including Hammer CLI:

      # satellite-installer \
      --foreman-ipa-authentication-api true \
      --foreman-ipa-authentication true
      Copy to Clipboard Toggle word wrap
      Warning

      Enabling access to both the Satellite web UI and the Satellite API poses a security risk. After the Identity Management user enters kinit to receive a Kerberos ticket-granting ticket (TGT), an attacker might obtain an API session. The attack is possible even if the user did not previously enter the Satellite login credentials anywhere, for example in the browser.

    • To disable external authentication with Identity Management, reset the options. For example, to disable access to the Satellite API and Hammer CLI:

      # satellite-installer --reset-foreman-ipa-authentication-api
      Copy to Clipboard Toggle word wrap
  2. If your Satellite Server runs in an IPv6-only network and also runs on RHEL 9.6 and earlier or RHEL 10.0, set the lookup_family_order option in the [domain/idm-server.example.com] section of the /etc/sssd/sssd.conf file:

    [domain/idm-server.example.com]
    lookup_family_order = ipv6_only
    Copy to Clipboard Toggle word wrap

    If the DNS name of the IdM server can be translated to both an IPv4 and IPv6 address but the IPv4 address is not accessible, SSSD requires lookup_family_order to translate the DNS name correctly. Without the option, IdM users are unable to use kinit to authenticate to Satellite.

Verification

  • Log in to Satellite web UI by entering the credentials of a user defined in Identity Management.

You can use host-based access control (HBAC) rules to manage access control within your Identity Management domain. In Identity Management, HBAC rules define which users can access which hosts and which services can be used to gain access.

For example, you can configure HBAC on the Identity Management server to limit access to Satellite Server only to selected users or user groups. By configuring a HBAC rule in the Identity Management domain, you can ensure Satellite does not create database entries for users who should not have access.

Prerequisites

  • Identity Management user account with privileges to configure HBAC rules

Procedure

  1. On the Identity Management server, configure HBAC control. For more information, see Red Hat Enterprise Linux 9 Managing IdM users, groups, hosts, and access control rules.

    1. Create a HBAC service for Satellite Server.
    2. Create a new HBAC rule to define the required access control. Add the following Identity Management entities to the HBAC rule:

      1. The HBAC service for Satellite Server
      2. The Satellite Server host
      3. The users or user groups to whom you want to grant access
    3. Make sure the default Identity Management allow_all rule is disabled. For information about how to disable allow_all without disrupting other services, see the How to configure HBAC rules in IdM article on the Red Hat Customer Portal.
  2. On your Satellite Server, load the host-based access control rules from Identity Management:

    # satellite-installer --foreman-pam-service foreman-prod
    Copy to Clipboard Toggle word wrap

Verification

  • Log in to the Satellite web UI as a user defined in Identity Management.

    • If the user is included in the HBAC rule, Satellite web UI will grant access.
    • If the user is not included in the HBAC rule, Satellite web UI will not grant access.

Example 3.2. Configuring host-based access control to allow access to Satellite only for selected Identity Management users by using the command line

On the Identity Management server, a user with administrative privileges configures a HBAC rule to allow selected users access to Satellite Server:

  1. Authenticate as the user with privileges required to configure HBAC rules:

    $ kinit admin
    Copy to Clipboard Toggle word wrap
  2. Optional: Verify that you have authenticated successfully:

    $ klist
    Copy to Clipboard Toggle word wrap
  3. Create a new HBAC service named satellite-prod:

    $ ipa hbacsvc-add satellite-prod
    Copy to Clipboard Toggle word wrap
  4. Create a new HBAC rule:

    $ ipa hbacrule-add allow-satellite-prod
    Copy to Clipboard Toggle word wrap
  5. Add the following Identity Management entities to the HBAC rule:

    1. The satellite-prod HBAC service:

      $ ipa hbacrule-add-service allow-satellite-prod --hbacsvcs=satellite-prod
      Copy to Clipboard Toggle word wrap
    2. The Satellite Server host:

      $ ipa hbacrule-add-host allow-satellite-prod --hosts=satellite.example.com
      Copy to Clipboard Toggle word wrap
    3. The users or user groups to whom you want to grant access:

      $ ipa hbacrule-add-user allow-satellite-prod --user=ipa-user
      Copy to Clipboard Toggle word wrap
  6. Optional: Verify the status of the rule:

    $ ipa hbacrule-find satellite-prod
    $ ipa hbactest --user=ipa-user --host=satellite.example.com --service=satellite-prod
    Copy to Clipboard Toggle word wrap
  7. Disable the default allow_all rule:
$ ipa hbacrule-disable allow_all
Copy to Clipboard Toggle word wrap

On Satellite Server, a Satellite administrator re-runs satellite-installer to load the host-based access control rules from Identity Management:

# satellite-installer --foreman-pam-service satellite-prod
Copy to Clipboard Toggle word wrap

Configure the Satellite Hammer CLI tool to use Identity Management to authenticate users.

Prerequisites

Procedure

  • Open the ~/.hammer/cli.modules.d/foreman.yml file on your Satellite Server and update the list of foreman parameters:

    • To enforce session usage, enable :use_sessions::

      :foreman:
        :use_sessions: true
      Copy to Clipboard Toggle word wrap

      With this configuration, you will need to initiate an authentication session manually with hammer auth login negotiate.

    • Alternatively, to enforce session usage and also negotiate authentication by default:

      :foreman:
        :default_auth_type: 'Negotiate_Auth'
        :use_sessions: true
      Copy to Clipboard Toggle word wrap

      With this configuration, Hammer will negotiate authentication automatically when you enter the first hammer command.

Authenticate to the Satellite Hammer CLI with your Identity Management username and password.

Prerequisites

Procedure

  1. Authenticate as a user defined in Identity Management to obtain a Kerberos ticket-granting ticket (TGT):

    $ kinit Identity_Management_user
    Copy to Clipboard Toggle word wrap
    Warning

    If you enabled access to the Satellite API and the Satellite web UI when you were configuring Identity Management as the authentication provider for Satellite, an attacker might now obtain an API session after the user receives the Kerberos TGT. The attack is possible even if the user did not previously enter the Satellite login credentials anywhere, for example in the browser.

  2. If Hammer is not configured to negotiate authentication, initiate an authentication session manually:

    $ hammer auth login negotiate
    Copy to Clipboard Toggle word wrap
Note

If you destroy the active Kerberos ticket, for example with kdestroy, you will still be logged in to Hammer. To log out, enter hammer auth logout.

Verification

  • Use any hammer command to check that the system does not ask you to authenticate. For example:

    $ hammer host list
    Copy to Clipboard Toggle word wrap

Additional resources

  • Run hammer auth --help to view all Hammer CLI authentication configuration options.
  • For more information about authenticating with Hammer, see Hammer authentication in Using the Hammer CLI tool.

You can use Mozilla Firefox to log in to the Satellite web UI with your Identity Management credentials.

Use the latest stable Mozilla Firefox browser.

Prerequisites

Procedure

  1. Obtain the Kerberos ticket granting ticket (TGT):

    $ kinit user
    Password for user@EXAMPLE.COM:
    Copy to Clipboard Toggle word wrap
  2. In Mozilla Firefox, go to the URL of your Satellite Server.
  3. You are logged in automatically.

Alternatively:

  1. In your browser address bar, enter the URL of your Satellite Server.
  2. Enter your username and password.

You can use Chrome to log in to the Satellite web UI with your Identity Management credentials.

Use the latest stable Chrome browser.

Prerequisites

Procedure

  1. Enable the Chrome browser to use Kerberos authentication:

    $ google-chrome --auth-server-whitelist="*.example.com" --auth-negotiate-delegate-whitelist="*.example.com"
    Copy to Clipboard Toggle word wrap
    Note

    Instead of allowlisting the whole domain, you can also allowlist a specific Satellite Server.

  2. Obtain the Kerberos ticket-granting ticket (TGT):

    $ kinit user
    Password for user@EXAMPLE.COM:
    Copy to Clipboard Toggle word wrap
  3. In Chrome, go to the URL of your Satellite Server.
  4. You are logged in automatically.

Alternatively:

  1. In your browser address bar, enter the URL of your Satellite Server.
  2. Enter your username and password.

When your Identity Management deployment includes a cross-forest trust with Active Directory (AD), configure host-based access control (HBAC) and the System Security Services Daemon (SSSD) to enable AD users to log in to Satellite.

Prerequisites

Procedure

On your Identity Management server:

  1. Enable HBAC:

    1. Create an external group and add the AD group to it.
    2. Add the new external group to a POSIX group.
    3. Use the POSIX group in a HBAC rule.

On your Identity Management server and all replicas in your Identity Management topology, configure SSSD to transfer additional attributes of AD users:

  1. Add the AD user attributes to the nss and domain sections in /etc/sssd/sssd.conf. For example:

    [domain/EXAMPLE.com]
    ...
    krb5_store_password_if_offline = True
    ldap_user_extra_attrs=email:mail, lastname:sn, firstname:givenname
    
    [nss]
    user_attributes=+email, +firstname, +lastname
    
    [ifp]
    allowed_uids = ipaapi, root
    user_attributes=+email, +firstname, +lastname
    Copy to Clipboard Toggle word wrap
  2. Clear the SSSD cache:

    1. Stop SSSD:

      # systemctl stop sssd
      Copy to Clipboard Toggle word wrap
    2. Clear the cache:

      # sss_cache -E
      Copy to Clipboard Toggle word wrap
    3. Start SSSD:

      # systemctl start sssd
      Copy to Clipboard Toggle word wrap
  3. Verify the AD attributes value by using the dbus-send command on your Satellite Server and on your Identity Management server. Make sure that both outputs match.

    # dbus-send --print-reply --system --dest=org.freedesktop.sssd.infopipe /org/freedesktop/sssd/infopipe org.freedesktop.sssd.infopipe.GetUserAttr string:ad-user@ad-domain array:string:email,firstname,lastname
    Copy to Clipboard Toggle word wrap
Important

Configuring Satellite with Red Hat Single Sign-On is a deprecated feature. Deprecated functionality is still included in Satellite and continues to be supported. However, it will be removed in a future release of this product and is not recommended for new deployments.

For the most recent list of major functionality that has been deprecated or removed within Satellite, refer to the Deprecated features section of the Satellite release notes.

Note

The Red Hat Single Sign-On 7 product family has reached End of Full Support. Use Red Hat build of Keycloak instead in your Satellite deployments. For information about configuring Red Hat build of Keycloak authentication, see Chapter 5, Configuring SSO and 2FA with Red Hat build of Keycloak in Satellite.

For information about migrating from Red Hat Single Sign-On to Red Hat build of Keycloak, see documentation for Red Hat build of Keycloak.

Red Hat Single Sign-On is an open-source identity and access management solution that provides authentication features, such as single sign-on functionality, user federation, and centralized authentication management. With Red Hat Single Sign-On, you can integrate Satellite Server with your existing Red Hat Single Sign-On server to delegate user authentication and authorization to Red Hat Single Sign-On.

Red Hat Single Sign-On users can log in using the following login methods:

  • User name and password in Satellite web UI
  • User name and password in Hammer CLI
Note

Red Hat Single Sign-On users cannot use both Satellite web UI and Hammer CLI authentication in Satellite at the same time.

  • Time-based one-time password (TOTP)

For information about Red Hat Single Sign-On, see Red Hat Single Sign-On documentation.

On your Satellite Server:

  • Install the packages required for registering a Red Hat Single Sign-On client:

    # satellite-maintain packages install mod_auth_openidc keycloak-httpd-client-install python3-lxml
    Copy to Clipboard Toggle word wrap

On the Red Hat Single Sign-On side, ensure you meet the following requirements:

  • Your Red Hat Single Sign-On server uses HTTPS instead of HTTP.
  • If the certificates or the CA are self-signed, they have been added to the end-user certificate truststore.
  • Your Red Hat Single Sign-On account has administrative privileges.
  • A realm is created on the Red Hat Single Sign-On server for Satellite user accounts, for example Satellite_Realm.
  • User accounts have been imported or added to Red Hat Single Sign-On. For more information about importing or creating users, see the Red Hat Single Sign-On Server Administration Guide.

Users defined in Red Hat Single Sign-On can authenticate to Satellite by using one of the following methods:

  • The Satellite web UI
  • Hammer CLI

Choose one of these methods to enable in your Satellite deployment.

Procedure

On your Satellite Server:

  1. Choose the authentication method you want Red Hat Single Sign-On users to use when authenticating to Satellite:

    • If you want users to authenticate by using the Satellite web UI:

      1. Create a client for Satellite. Use foreman-openidc as the application name.

        # keycloak-httpd-client-install --app-name foreman-openidc \
        --keycloak-server-url "https://rhsso.example.com" \
        --keycloak-admin-username "admin" \
        --keycloak-realm "Satellite_Realm" \
        --keycloak-admin-realm master \
        --keycloak-auth-role root-admin \
        -t openidc -l /users/extlogin --force
        Copy to Clipboard Toggle word wrap
      2. Configure Satellite to use Red Hat Single Sign-On as an authentication source for Satellite web UI:

        # satellite-installer --foreman-keycloak true \
        --foreman-keycloak-app-name "foreman-openidc" \
        --foreman-keycloak-realm "Satellite_Realm"
        Copy to Clipboard Toggle word wrap
    • If you want users to authenticate by using the Hammer CLI:

      1. Create a client for Satellite. Use hammer-openidc as the application name.

        # keycloak-httpd-client-install --app-name hammer-openidc \
        --keycloak-server-url "https://rhsso.example.com" \
        --keycloak-admin-username "admin" \
        --keycloak-realm "Satellite_Realm" \
        --keycloak-admin-realm master \
        --keycloak-auth-role root-admin \
        -t openidc -l /users/extlogin --force
        Copy to Clipboard Toggle word wrap
      2. Configure Satellite to use Red Hat Single Sign-On as an authentication source for Hammer CLI:

        # satellite-installer --foreman-keycloak true \
        --foreman-keycloak-app-name "hammer-openidc" \
        --foreman-keycloak-realm "Satellite_Realm"
        Copy to Clipboard Toggle word wrap
  2. Restart the httpd service:

    # systemctl restart httpd
    Copy to Clipboard Toggle word wrap

Configure the Satellite client in Red Hat Single Sign-On with valid redirect URIs and mappers.

Procedure

In the Red Hat Single Sign-On web UI:

  1. Go to the realm created for Satellite users. Navigate to Clients and click the Satellite client.
  2. Configure access type:

    • If you are configuring a client that will provide Satellite web UI authentication, select confidential from the Access Type list.
    • If you are configuring a client that will provide Hammer CLI authentication, select public from the Access Type list.
  3. Configure Valid redirect URI addresses:

    • If you are configuring a client that will provide Satellite web UI authentication:

      • You will see a pre-defined URI: https://satellite.example.com/users/extlogin/redirect_uri. Do not change or remove this URI.
      • Add another URI below the pre-defined URI: https://satellite.example.com/users/extlogin
    • If you are configuring a client that will provide Hammer CLI authentication:

      • You will see a pre-defined URI: https://satellite.example.com/users/extlogin/redirect_uri. Do not change or remove this URI.
      • Add another URI below the pre-defined URI: urn:ietf:wg:oauth:2.0:oob
  4. Click Save.
  5. On the Mappers tab, click Create to add an audience mapper.

    1. From the Mapper Type list, select Audience.
    2. From the Included Client Audience list, select the Satellite client.
  6. Click Save.
  7. On the Mappers tab, click Create to add a group mapper so that you can specify authorization in Satellite based on group membership.

    1. From the Mapper Type list, select Group Membership.
    2. In the Token Claim Name field, enter groups.
    3. Set the Full group path setting to OFF.
  8. Click Save.

Additional resources

If you are configuring a client that will provide Satellite web UI authentication to your Satellite deployment, delegate authentication to the Red Hat Single Sign-On server and add Red Hat Single Sign-On as an external authentication source in Satellite.

Prerequisites

Procedure

In the Satellite web UI:

  1. Navigate to Administer > Settings.
  2. On the Authentication tab, configure the following settings:

    1. Authorize login delegation: Set to Yes.
    2. Authorize login delegation auth source user autocreate: Set to External.
    3. Login delegation logout URL: Set to https://satellite.example.com/users/extlogout.
    4. OIDC Algorithm: For example, set to RS256.
    5. OIDC Audience: Set to the client ID for Red Hat Single Sign-On.
    6. OIDC Issuer: Set to https://rhsso.example.com/auth/realms/Satellite_Realm.
    7. OIDC JWKs URL: Set to https://rhsso.example.com/auth/realms/Satellite_Realm/protocol/openid-connect/certs.
  3. Navigate to Administer > Authentication Sources.

    1. From the External menu, select Edit.
    2. On the Locations tab, add the locations that you want to be able to use the Red Hat Single Sign-On authentication source.
    3. On the Organizations tab, add the organizations that you want to be able to use the Red Hat Single Sign-On authentication source.
    4. Click Submit.

If you are configuring a client that will provide Hammer CLI authentication to your Satellite deployment, delegate authentication to the Red Hat Single Sign-On server and add Red Hat Single Sign-On as an external authentication source in Satellite.

Prerequisites

  • Ensure that the Access Type setting in the Satellite client in the Red Hat Single Sign-On web UI is set to public. For more information, see Section 4.3, “Configuring the Satellite client in Red Hat Single Sign-On”.
  • Obtain the values to configure Satellite settings from the following URL: https://rhsso.example.com/auth/realms/Satellite_Realm/.well-known/openid-configuration. Replace Satellite_Realm with the name of the Red Hat Single Sign-On realm created for your Satellite server.

Procedure

On the Satellite client registered to Red Hat Single Sign-On:

  1. Set the login delegation to true so that users can authenticate using the Open IDC protocol:

    $ hammer settings set --name authorize_login_delegation --value true
    Copy to Clipboard Toggle word wrap
  2. Set the login delegation logout URL:

    $ hammer settings set --name login_delegation_logout_url \
    --value https://satellite.example.com/users/extlogout
    Copy to Clipboard Toggle word wrap
  3. Set the algorithm for encoding: For example, to use the RS256 algorithm:

    $ hammer settings set --name oidc_algorithm --value 'RS256'
    Copy to Clipboard Toggle word wrap
  4. Add the value for the Hammer client in the Open IDC audience:

    $ hammer settings set --name oidc_audience \
    --value "['satellite.example.com-hammer-openidc']"
    Copy to Clipboard Toggle word wrap
  5. Set the value for the Open IDC issuer:

    $ hammer settings set --name oidc_issuer \
    --value "https://rhsso.example.com/auth/realms/Satellite_Realm"
    Copy to Clipboard Toggle word wrap
  6. Set the value for Open IDC Java Web Token (JWT):

    $ hammer settings set --name oidc_jwks_url \
    --value "https://rhsso.example.com/auth/realms/Satellite_Realm/protocol/openid-connect/certs"
    Copy to Clipboard Toggle word wrap
  7. Retrieve the ID of the Red Hat Single Sign-On authentication source:

    $ hammer auth-source external list
    Copy to Clipboard Toggle word wrap
  8. Set the location and organization:

    $ hammer auth-source external update \
    --id My_Authentication_Source_ID \
    --location-ids My_Location_ID \
    --organization-ids My_Organization_ID
    Copy to Clipboard Toggle word wrap

If you want users to authenticate with time-based one-time passwords (TOTP), configure an OTP policy for the Satellite realm in Red Hat Single Sign-On.

Procedure

  1. In the Red Hat Single Sign-On web UI, navigate to the Satellite realm.
  2. Navigate to Authentication.
  3. On the Policies tab, click the OTP Policy tab. Ensure that the Supported Applications field includes FreeOTP or Google Authenticator.
  4. Configure the OTP settings to suit your requirements.
  5. On Required Actions tab, enable the Set as default action setting for the Configure OTP action.

To implement the role-based access control (RBAC), create a group in Satellite, assign a role to this group, and then map an Red Hat Single Sign-On group to the Satellite group. As a result, anyone in the given group in Red Hat Single Sign-On will log in under the corresponding Satellite group.

For example, you can configure users of the Satellite-admin user group defined in Active Directory to authenticate as users with administrator privileges on Satellite.

If you do not configure group mapping, every user will receive the Default role permissions.

Procedure

  1. In the Satellite web UI, navigate to Administer > User Groups.
  2. Click Create User Group.

    1. In the Name field, enter a name for the user group. Enter a name that is different from the Active Directory user group name.
    2. Do not add any users or user groups to the new group in Satellite web UI.
  3. On the Roles tab, select Administer.
  4. On the External Groups tab, click Add external user group.

    1. In the Name field, enter the name of the Active Directory group.
    2. From the Auth Source drop-down menu, select EXTERNAL.
  5. Click Submit.

With Red Hat Single Sign-On configured as an external authentication source for Satellite, users defined in a Red Hat Single Sign-On realm can log in to Satellite Server. The particular login methods available to users depend on how you configured integration between Red Hat Single Sign-On and Satellite.

Procedure

To authenticate to the Satellite web UI:

  • In your browser, go to https://satellite.example.com and enter your credentials.

To authenticate to the Satellite web UI by using Red Hat Single Sign-On TOTP:

  1. In your browser, log in to Satellite. Satellite redirects you to the Red Hat Single Sign-On login screen.
  2. Enter your username and password, and click Log In.
  3. On your first login attempt, Red Hat Single Sign-On requests you to configure your client by scanning the bar code and entering your PIN. Once authenticated, your browser redirects you back to Satellite and logs you in.

To authenticate to the Satellite CLI with Hammer:

  1. Ensure that Hammer is configured to enforce session usage in ~/.hammer/cli.modules.d/foreman.yml:

    :foreman:
      :use_sessions: true
    Copy to Clipboard Toggle word wrap
  2. Initiate an authentication session with hammer auth login oauth:

    $ hammer auth login oauth \
    --oidc-token-endpoint 'https://rhsso.example.com/auth/realms/Satellite_realm/protocol/openid-connect/token' \
    --oidc-authorization-endpoint 'https://rhsso.example.com/auth' \
    --oidc-client-id 'satellite.example.com-hammer-openidc' \
    --oidc-redirect-uri urn:ietf:wg:oauth:2.0:oob
    Copy to Clipboard Toggle word wrap

To authenticate to the Satellite CLI with Hammer by using Red Hat Single Sign-On TOTP:

  1. Ensure that Hammer is configured to enforce session usage in ~/.hammer/cli.modules.d/foreman.yml:

    :foreman:
      :use_sessions: true
    Copy to Clipboard Toggle word wrap
  2. Initiate an authentication session by using --two-factor with hammer auth login oauth:

    $ hammer auth login oauth \
    --two-factor \
    --oidc-token-endpoint 'https://rhsso.example.com/auth/realms/Satellite_realm/protocol/openid-connect/token' \
    --oidc-authorization-endpoint 'https://rhsso.example.com/auth' \
    --oidc-client-id 'satellite.example.com-hammer-openidc' \
    --oidc-redirect-uri urn:ietf:wg:oauth:2.0:oob
    Copy to Clipboard Toggle word wrap
  3. You will be prompted to enter a success code. To retrieve the success code, navigate to the URL that the command returns.
  4. Enter the success code in CLI.

Red Hat build of Keycloak is an open-source identity and access management solution that provides authentication features, such as single sign-on functionality, user federation, and centralized authentication management. With Red Hat build of Keycloak, you can integrate Satellite Server with your existing Red Hat build of Keycloak server to delegate user authentication and authorization to Red Hat build of Keycloak.

Red Hat build of Keycloak users can log in using the following login methods:

  • User name and password in Satellite web UI
  • User name and password in Hammer CLI
Note

Red Hat build of Keycloak users cannot use both Satellite web UI and Hammer CLI authentication in Satellite at the same time.

  • Time-based one-time password (TOTP), an implementation of two-factor authentication (2FA)

For information about Red Hat build of Keycloak, see Red Hat build of Keycloak documentation.

On your Satellite Server:

  • Install the packages required for registering a Red Hat build of Keycloak client:

    # satellite-maintain packages install mod_auth_openidc keycloak-httpd-client-install python3-lxml
    Copy to Clipboard Toggle word wrap
  • Check which keycloak-httpd-client-install version is installed:

    # rpm --query keycloak-httpd-client-install
    Copy to Clipboard Toggle word wrap

On the Red Hat build of Keycloak side, ensure you meet the following requirements:

  • If keycloak-httpd-client-install version 1.2 or earlier is installed on your Satellite Server, make sure to use the appropriate context path:

    • You can use a Red Hat build of Keycloak server that has been initialized with the --http-relative-path=/auth context path. To access a Red Hat build of Keycloak server initialized with --http-relative-path=/auth from its web UI, go to https://rhbk.example.com:8443/auth.
    • If you want to use a different context path, make manual adjustments after the initialization with /auth or configure the foreman-openidc_oidc_keycloak_Foreman_Realm.conf file of the HTTPd service manually. For more information about configuring a different context path, see the Red Hat build of Keycloak Administration Guide.
  • If keycloak-httpd-client-install version 1.3 or later is installed, your Red Hat build of Keycloak server does not need to be initialized with the --http-relative-path=/auth context path.
  • Your Red Hat build of Keycloak server uses HTTPS instead of HTTP.
  • If the certificates or the CA are self-signed, they have been added to the end-user certificate truststore.
  • Your Red Hat build of Keycloak account has administrative privileges.
  • A realm is created on the Red Hat build of Keycloak server for Satellite user accounts, for example Satellite_Realm.
  • User accounts have been imported or added to Red Hat build of Keycloak. For more information on importing or creating users, see the Red Hat build of Keycloak Administration Guide.

Users defined in Red Hat build of Keycloak can authenticate to Satellite by using one of the following methods:

  • The Satellite web UI
  • Hammer CLI

Choose one of these methods to enable in your Satellite deployment.

Procedure

On your Satellite Server:

  1. Choose the authentication method you want Red Hat build of Keycloak users to use when authenticating to Satellite:

    • If you want users to authenticate by using the Satellite web UI:

      1. Create a client for Satellite. Use foreman-openidc as the application name.

        # keycloak-httpd-client-install --app-name foreman-openidc \
        --keycloak-server-url "https://rhbk.example.com:8443" \
        --keycloak-admin-username "admin" \
        --keycloak-realm "Satellite_Realm" \
        --keycloak-admin-realm master \
        --keycloak-auth-role root-admin \
        -t openidc -l /users/extlogin --force
        Copy to Clipboard Toggle word wrap
      2. Configure Satellite to use Red Hat build of Keycloak as an authentication source for Satellite web UI:

        # satellite-installer --foreman-keycloak true \
        --foreman-keycloak-app-name "foreman-openidc" \
        --foreman-keycloak-realm "Satellite_Realm"
        Copy to Clipboard Toggle word wrap
    • If you want users to authenticate by using the Hammer CLI:

      1. Create a client for Satellite. Use hammer-openidc as the application name.

        # keycloak-httpd-client-install --app-name hammer-openidc \
        --keycloak-server-url "https://rhbk.example.com:8443" \
        --keycloak-admin-username "admin" \
        --keycloak-realm "Satellite_Realm" \
        --keycloak-admin-realm master \
        --keycloak-auth-role root-admin \
        -t openidc -l /users/extlogin --force
        Copy to Clipboard Toggle word wrap
      2. Configure Satellite to use Red Hat build of Keycloak as an authentication source for Hammer CLI:

        # satellite-installer --foreman-keycloak true \
        --foreman-keycloak-app-name "hammer-openidc" \
        --foreman-keycloak-realm "Satellite_Realm"
        Copy to Clipboard Toggle word wrap
  2. Restart the httpd service:

    # systemctl restart httpd
    Copy to Clipboard Toggle word wrap

Configure the Satellite client in Red Hat build of Keycloak with valid redirect URIs and mappers.

Procedure

In the Red Hat build of Keycloak web UI:

  1. Go to the realm created for Satellite users.
  2. Navigate to Clients and click the Satellite client.
  3. On the Settings tab for the Satellite client, configure the access type and redirect addresses:

    • If you are configuring a client that will provide Satellite web UI authentication:

      1. Enable Client authentication.
      2. You will see a pre-defined URI: https://satellite.example.com/users/extlogin/redirect_uri. Do not change or remove this URI.
      3. Add another URI below the pre-defined URI: https://satellite.example.com/users/extlogin
    • If you are configuring a client that will provide Hammer CLI authentication:

      1. Ensure Client authentication is disabled.
      2. You will see a pre-defined URI: https://satellite.example.com/users/extlogin/redirect_uri. Do not change or remove this URI.
      3. Add another URI below the pre-defined URI: urn:ietf:wg:oauth:2.0:oob
  4. On the Client Scopes tab for the Satellite client, locate the client scope dedicated to the Satellite client named client-name-dedicated. Start editing the client scope.

    1. On the Mappers tab for client-name-dedicated, add a new mapper by configuration. Select the Audience mapper type.

      1. From the Included Client Audience list, select the Satellite client.
      2. Enable Add to ID token.
      3. Click Save.
    2. Add another mapper by configuration. Select the Group Membership mapper type. This adds a group mapper so that you can specify authorization in Satellite based on group membership.

      1. In the Token Claim Name field, enter groups.
      2. Disable Full group path.
      3. Click Save.

Additional resources

If you are configuring a client that will provide Satellite web UI authentication to your Satellite deployment, delegate authentication to the Red Hat build of Keycloak server and add Red Hat build of Keycloak as an external authentication source in Satellite.

Prerequisites

Procedure

In the Satellite web UI:

  1. Navigate to Administer > Settings.
  2. On the Authentication tab, configure the following settings:

    1. Authorize login delegation: Set to Yes.
    2. Authorize login delegation auth source user autocreate: Set to External.
    3. Login delegation logout URL: Set to https://satellite.example.com/users/extlogout.
    4. OIDC Algorithm: For example, set to RS256.
    5. OIDC Audience: Set to the client ID for Red Hat build of Keycloak.
    6. OIDC Issuer:

      • Set to https://rhbk.example.com:8443/realms/Satellite_Realm if you initialized your Red Hat build of Keycloak server without the --http-relative-path=/auth context path.
      • Set to https://rhbk.example.com:8443/auth/realms/Satellite_Realm if you initialized your Red Hat build of Keycloak server with the --http-relative-path=/auth context path.
    7. OIDC JWKs URL:

      • Set to https://rhbk.example.com:8443/realms/Satellite_Realm/protocol/openid-connect/certs if you initialized your Red Hat build of Keycloak server without the --http-relative-path=/auth context path.
      • Set to https://rhbk.example.com:8443/auth/realms/Satellite_Realm/protocol/openid-connect/certs if you initialized your Red Hat build of Keycloak server with the --http-relative-path=/auth context path.
  3. Navigate to Administer > Authentication Sources.

    1. From the External menu, select Edit.
    2. On the Locations tab, add the locations that you want to be able to use the Red Hat build of Keycloak authentication source.
    3. On the Organizations tab, add the organizations that you want to be able to use the Red Hat build of Keycloak authentication source.
    4. Click Submit.

If you are configuring a client that will provide Hammer CLI authentication to your Satellite deployment, delegate authentication to the Red Hat build of Keycloak server and add Red Hat build of Keycloak as an external authentication source in Satellite.

Prerequisites

  • Ensure that the Client authentication setting in the Satellite client in the Red Hat build of Keycloak web UI is disabled. For more information, see Section 5.3, “Configuring the Satellite client in Red Hat build of Keycloak”.
  • If you initialized your Red Hat build of Keycloak server without the --http-relative-path=/auth context path, obtain the values to configure Satellite settings from the following URL: https://rhbk.example.com:8443/realms/Satellite_Realm/.well-known/openid-configuration. Replace Satellite_Realm with the name of the Red Hat build of Keycloak realm created for your Satellite Server.
  • If you initialized your Red Hat build of Keycloak server with the --http-relative-path=/auth context path, obtain the values to configure Satellite settings from the following URL: https://rhbk.example.com:8443/auth/realms/Satellite_Realm/.well-known/openid-configuration. Replace Satellite_Realm with the name of the Red Hat build of Keycloak realm created for your Satellite Server.

Procedure

On the Satellite client registered to Red Hat build of Keycloak:

  1. Set the login delegation to true so that users can authenticate using the Open IDC protocol:

    $ hammer settings set --name authorize_login_delegation --value true
    Copy to Clipboard Toggle word wrap
  2. Set the login delegation logout URL:

    $ hammer settings set --name login_delegation_logout_url \
    --value https://satellite.example.com/users/extlogout
    Copy to Clipboard Toggle word wrap
  3. Set the algorithm for encoding: For example, to use the RS256 algorithm:

    $ hammer settings set --name oidc_algorithm --value 'RS256'
    Copy to Clipboard Toggle word wrap
  4. Add the value for the Hammer client in the Open IDC audience:

    $ hammer settings set --name oidc_audience \
    --value "['satellite.example.com-hammer-openidc']"
    Copy to Clipboard Toggle word wrap
  5. Set the value for the Open IDC issuer:

    • If you initialized your Red Hat build of Keycloak server without the --http-relative-path=/auth context path:

      $ hammer settings set --name oidc_issuer \
      --value "https://rhbk.example.com:8443/realms/Satellite_Realm"
      Copy to Clipboard Toggle word wrap
    • If you initialized your Red Hat build of Keycloak server with the --http-relative-path=/auth context path:

      $ hammer settings set --name oidc_issuer \
      --value "https://rhbk.example.com:8443/auth/realms/Satellite_Realm"
      Copy to Clipboard Toggle word wrap
  6. Set the value for Open IDC Java Web Token (JWT):

    • If you initialized your Red Hat build of Keycloak server without the --http-relative-path=/auth context path:

      $ hammer settings set --name oidc_jwks_url \
      --value "https://rhbk.example.com:8443/realms/Satellite_Realm/protocol/openid-connect/certs"
      Copy to Clipboard Toggle word wrap
    • If you initialized your Red Hat build of Keycloak server with the --http-relative-path=/auth context path:

      $ hammer settings set --name oidc_jwks_url \
      --value "https://rhbk.example.com:8443/auth/realms/Satellite_Realm/protocol/openid-connect/certs"
      Copy to Clipboard Toggle word wrap
  7. Retrieve the ID of the Red Hat build of Keycloak authentication source:

    $ hammer auth-source external list
    Copy to Clipboard Toggle word wrap
  8. Set the location and organization:

    $ hammer auth-source external update \
    --id My_Authentication_Source_ID \
    --location-ids My_Location_ID \
    --organization-ids My_Organization_ID
    Copy to Clipboard Toggle word wrap

If you want users to authenticate with time-based one-time passwords (TOTP), configure an OTP policy for the Satellite realm in Red Hat build of Keycloak.

Procedure

  1. In the Red Hat build of Keycloak web UI, navigate to the Satellite realm.
  2. Navigate to Authentication.
  3. On the Policies tab, click the OTP Policy tab. Ensure that the Supported Applications field includes FreeOTP or Google Authenticator.
  4. Configure the OTP settings to suit your requirements.
  5. On Required Actions tab, enable the Set as default action setting for the Configure OTP action.

To implement the role-based access control (RBAC), create a group in Satellite, assign a role to this group, and then map an Red Hat build of Keycloak group to the Satellite group. As a result, anyone in the given group in Red Hat build of Keycloak will log in under the corresponding Satellite group.

For example, you can configure users of the Satellite-admin user group defined in Active Directory to authenticate as users with administrator privileges on Satellite.

If you do not configure group mapping, every user will receive the Default role permissions.

Procedure

  1. In the Satellite web UI, navigate to Administer > User Groups.
  2. Click Create User Group.

    1. In the Name field, enter a name for the user group. Enter a name that is different from the Active Directory user group name.
    2. Do not add any users or user groups to the new group in Satellite web UI.
  3. On the Roles tab, select Administer.
  4. On the External Groups tab, click Add external user group.

    1. In the Name field, enter the name of the Active Directory group.
    2. From the Auth Source drop-down menu, select EXTERNAL.
  5. Click Submit.

With Red Hat build of Keycloak configured as an external authentication source for Satellite, users defined in a Red Hat build of Keycloak realm can log in to Satellite Server. The particular login methods available to users depend on how you configured integration between Red Hat build of Keycloak and Satellite.

Procedure

To authenticate to the Satellite web UI:

  • In your browser, go to https://satellite.example.com and enter your credentials.

To authenticate to the Satellite web UI by using Red Hat build of Keycloak TOTP:

  1. In your browser, log in to Satellite. Satellite redirects you to the Red Hat build of Keycloak login screen.
  2. Enter your username and password, and click Log In.
  3. On your first login attempt, Red Hat build of Keycloak requests you to configure your client by scanning the bar code and entering your PIN. Once authenticated, your browser redirects you back to Satellite and logs you in.

To authenticate to the Satellite CLI with Hammer:

  1. Ensure that Hammer is configured to enforce session usage in ~/.hammer/cli.modules.d/foreman.yml:

    :foreman:
      :use_sessions: true
    Copy to Clipboard Toggle word wrap
  2. Initiate an authentication session with hammer auth login oauth:

    • If you initialized your Red Hat build of Keycloak server without the --http-relative-path=/auth context path:

      $ hammer auth login oauth \
      --oidc-token-endpoint 'https://rhbk.example.com:8443/realms/Satellite_realm/protocol/openid-connect/token' \
      --oidc-authorization-endpoint 'https://rhbk.example.com:8443' \
      --oidc-client-id 'satellite.example.com-hammer-openidc' \
      --oidc-redirect-uri urn:ietf:wg:oauth:2.0:oob
      Copy to Clipboard Toggle word wrap
    • If you initialized your Red Hat build of Keycloak server with the --http-relative-path=/auth context path:

      $ hammer auth login oauth \
      --oidc-token-endpoint 'https://rhbk.example.com:8443/auth/realms/Satellite_realm/protocol/openid-connect/token' \
      --oidc-authorization-endpoint 'https://rhbk.example.com:8443/auth' \
      --oidc-client-id 'satellite.example.com-hammer-openidc' \
      --oidc-redirect-uri urn:ietf:wg:oauth:2.0:oob
      Copy to Clipboard Toggle word wrap

To authenticate to the Satellite CLI with Hammer by using Red Hat build of Keycloak TOTP:

  1. Ensure that Hammer is configured to enforce session usage in ~/.hammer/cli.modules.d/foreman.yml:

    :foreman:
      :use_sessions: true
    Copy to Clipboard Toggle word wrap
  2. Initiate an authentication session by using --two-factor with hammer auth login oauth:

    $ hammer auth login oauth \
    --two-factor \
    --oidc-token-endpoint 'https://rhbk.example.com:8443/auth/realms/Satellite_realm/protocol/openid-connect/token' \
    --oidc-authorization-endpoint 'https://rhbk.example.com:8443/auth' \
    --oidc-client-id 'satellite.example.com-hammer-openidc' \
    --oidc-redirect-uri urn:ietf:wg:oauth:2.0:oob
    Copy to Clipboard Toggle word wrap
  3. You will be prompted to enter a success code. To retrieve the success code, navigate to the URL that the command returns.
  4. Enter the success code in CLI.

If the base system of your Satellite Server is connected directly to Active Directory (AD), you can configure AD as an external authentication source for Satellite. Direct AD integration means that a Linux system is joined directly to the AD domain where the identity is stored.

AD users can log in using the following methods:

  • Username and password
  • Kerberos single sign-on
Note

You can also connect your Satellite deployment to AD in the following ways:

Enable Active Directory (AD) users to access Satellite by configuring the corresponding authentication provider on your Satellite Server.

Prerequisites

  • The base system of your Satellite Server must be joined to an Active Directory (AD) domain. To enable AD users to sign in with Kerberos single sign-on, use the System Security Services Daemon (SSSD) and Samba services to join the base system to the AD domain:

    Install the following packages on Satellite Server:

    # satellite-maintain packages install adcli krb5-workstation oddjob-mkhomedir oddjob realmd samba-winbind-clients samba-winbind samba-common-tools samba-winbind-krb5-locator sssd
    Copy to Clipboard Toggle word wrap

    Specify the required software when joining the AD domain:

    # realm join AD.EXAMPLE.COM --membership-software=samba --client-software=sssd
    Copy to Clipboard Toggle word wrap

    For more information on direct AD integration, see Connecting RHEL systems directly to AD using Samba Winbind.

Procedure

  1. Define AD realm configuration in a location where satellite-installer expects it:

    1. Create a directory named /etc/ipa/:

      # mkdir /etc/ipa/
      Copy to Clipboard Toggle word wrap
    2. Create the /etc/ipa/default.conf file with the following contents to configure the Kerberos realm for the AD domain:

      [global]
      realm = AD.EXAMPLE.COM
      Copy to Clipboard Toggle word wrap
  2. Configure the Apache keytab for Kerberos connections:

    1. Update the /etc/samba/smb.conf file with the following settings to configure how Samba interacts with AD:

      [global]
      workgroup = AD.EXAMPLE
      realm = AD.EXAMPLE.COM
      kerberos method = system keytab
      security = ads
      Copy to Clipboard Toggle word wrap
    2. Add the Kerberos service principal to the keytab file at /etc/httpd/conf/http.keytab:

      # KRB5_KTNAME=FILE:/etc/httpd/conf/http.keytab net ads keytab create HTTP -U Administrator -s /etc/samba/smb.conf
      Copy to Clipboard Toggle word wrap
      Note

      The net ads keytab create command was introduced in Samba version 4.21.1. If your system uses an earlier version of Samba, use the net ads keytab add command.

  3. Configure the System Security Services Daemon (SSSD) on your Satellite Server:

    1. Configure the AD access control provider to evaluate and enforce Group Policy Object (GPO) access control rules for the foreman PAM service. In the [domain/ad.example.com] section of your /etc/sssd/sssd.conf file, set the ad_gpo_access_control and ad_gpo_map_service options as follows:

      [domain/ad.example.com]
      ad_gpo_access_control = enforcing
      ad_gpo_map_service = +foreman
      Copy to Clipboard Toggle word wrap

      For more information on GPOs, see How SSSD interprets GPO access control rules in Integrating RHEL systems directly with Windows Active Directory (RHEL 9).

    2. If your Satellite Server runs in an IPv6-only network and also runs on RHEL 9.6 and earlier or RHEL 10.0, set the lookup_family_order option in the [domain/ad.example.com] section of the /etc/sssd/sssd.conf file:

      [domain/ad.example.com]
      lookup_family_order = ipv6_only
      Copy to Clipboard Toggle word wrap

      If the DNS name of the AD server can be translated to both an IPv4 and IPv6 address but the IPv4 address is not accessible, SSSD requires lookup_family_order to translate the DNS name correctly. Without the option, AD users are unable to use kinit to authenticate to Satellite.

    3. Restart SSSD:

      # systemctl restart sssd
      Copy to Clipboard Toggle word wrap
  4. Enable the authentication source:

    # satellite-installer --foreman-ipa-authentication true
    Copy to Clipboard Toggle word wrap

Verification

  • To verify that AD users can log in to Satellite by entering their credentials, log in to Satellite web UI at https://satellite.example.com. Enter the user name in the user principal name (UPN) format, for example: ad_user@AD.EXAMPLE.COM.
  • To verify that AD users can authenticate by using Kerberos single sign-on:

    • Obtain a Kerberos ticket-granting ticket (TGT) on behalf of an AD user:

      $ kinit ad_user@AD.EXAMPLE.COM
      Copy to Clipboard Toggle word wrap
    • Verify user authentication by using your TGT:

      $ curl -k -u : --negotiate https://satellite.example.com/users/extlogin
      
      <html><body>You are being <a href="satellite.example.com/hosts">redirected</a>.</body></html>
      Copy to Clipboard Toggle word wrap

Troubleshooting

  • Connecting to the AD LDAP can sometimes fail with an error such as the following appearing in the logs:

    Authentication failed with status code: {
      "error": { "message": "ERF77-7629 [Foreman::LdapException]: Error while connecting to 'server.com' LDAP server at 'ldap.example.com' during authentication ([Net::LDAP::Error]: Connection reset by peer - SSL_connect)" } }
    Copy to Clipboard Toggle word wrap

    If you see this error, verify which cipher is used for the connection:

    # openssl s_client -connect ldap.example.com:636
    Copy to Clipboard Toggle word wrap

    If the TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 cipher is used, disable it on either the Satellite Server side or on the AD side. The TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 cipher is known to cause incompatibilities.

    For more information, see the Red Hat Knowledgebase solution API calls to Red Hat Satellite 6 fail intermittently on LDAP authentication.

Additional resources

Lightweight Directory Access Protocol (LDAP) is a set of open protocols used to access centrally stored information over a network. With Satellite, you can use one or multiple LDAP directories for external authentication.

Note

While you can configure the LDAP server integrated with Identity Management as an external authentication source, Identity Management users will not be able to log in by using single sign-on. Instead, consider configuring Identity Management as an external identity provider. For more information, see Chapter 3, Configuring Kerberos SSO with Identity Management in Satellite.

Important

Users cannot use both Identity Management and LDAP as an authentication method. After a user authenticates by using one of these methods, they cannot use the other method.

To change the authentication method for a user, remove the automatically created user from Satellite.

7.1. Configuring TLS for secure LDAP

If Satellite uses TLS to establish a secure LDAP connection (LDAPS), you must obtain the CA certificates of your LDAP server and add them to the trusted CA list on the base operating system of your Satellite Server.

Prerequisite

  • If your LDAP server uses a certificate chain with intermediate certificate authorities, the trusted CA list must contain all root and intermediate certificates.

Procedure

  1. Obtain the CA certificate from the LDAP Server:

    1. If you use Active Directory Certificate Services, export the Enterprise PKI CA Certificate using the Base64 encoded X.509 format. See How to configure Active Directory authentication with TLS on Satellite for information on creating and exporting a CA certificate from an Active Directory server.
    2. Download the LDAP server certificate to a temporary location on the Satellite Server, such as /tmp/example.crt. You will remove the certificate when finished.

      The filename extensions .cer and .crt are only conventions and can refer to DER binary or PEM ASCII format certificates.

  2. Add the LDAP server certificate to the system truststore:

    1. Import the certificate:

      # cp /tmp/example.crt /etc/pki/ca-trust/source/anchors
      Copy to Clipboard Toggle word wrap
    2. Update the certificate authority truststore:

      # update-ca-trust extract
      Copy to Clipboard Toggle word wrap
  3. Delete the downloaded LDAP certificate from the temporary location on your Satellite Server.
  4. Restart Satellite services:

    # satellite-maintain service restart
    Copy to Clipboard Toggle word wrap

Additional resources

  • For more information about adding certificates to the system truststore, see Using shared system certificates in Red Hat Enterprise Linux 9 Securing networks.

7.2. Configuring Satellite to use LDAP

Configure an LDAP authentication source to enable users to log in to Satellite with their existing LDAP credentials.

Prerequisites

  • Your LDAP server complies with the RFC 2307 schema.
  • Your user account has the following permissions:

    • view_authenticators, create_authenticators, edit_authenticators
    • view_locations, assign_locations
    • view_organizations, assign_organizations

Procedure

  1. On your Satellite Server, enable the Network Information System (NIS) service so that SELinux does not block outgoing LDAP connections:

    # setsebool -P nis_enabled on
    Copy to Clipboard Toggle word wrap
  2. In the Satellite web UI, navigate to Administer > Authentication Sources.
  3. From the LDAP menu, select Create.
  4. On the LDAP server tab, enter the details of your LDAP server.

    For TLS encrypted connections, select LDAPS to enable encryption.

  5. On the Account tab, enter the account information and domain name details. For more information, see the following sections:

  6. On the Attribute mappings tab, map LDAP attributes to Satellite attributes.
  7. On the Locations tab, select the locations you want Satellite to assign to users created from the LDAP authentication source. These locations are available to users after they log in for the first time.
  8. On the Organizations tab, select the organizations you want Satellite to assign to users created from the LDAP authentication source. These locations are available to users after they log in for the first time.
  9. Click Submit.

Next steps

  • If you did not select Automatically Create Accounts In Satellite on the Account tab, create user accounts manually. For more information, see Creating a User in Administering Red Hat Satellite.
  • If you selected Automatically Create Accounts In Satellite, LDAP users can now log in to Satellite using their LDAP accounts and passwords.
  • After users log in for the first time, the Satellite administrator must assign roles to them manually. For more information about assigning appropriate roles to user accounts, see Assigning Roles to a User in Administering Red Hat Satellite.

7.3. Example settings for LDAP connections

Example 7.1. Example settings for Active Directory LDAP connections

This example uses a dedicated service account called redhat that has bind, read, and search permissions on the user and group entries.

  • Account Username: DOMAIN\redhat
  • Account password: P@ssword
  • Base DN: DC=example,DC=COM
  • Login name attribute: userPrincipalName
  • First name attribute: givenName
  • Last name attribute: sn
  • Email address attribute: mail
  • Photo attribute: thumbnailPhoto

The userPrincipalName attribute allows the use of whitespace in usernames. The sAMAccountName attribute, which provides backwards compatibility with legacy Microsoft systems, does not allow the use of whitespace in usernames.

Example 7.2. Example settings for Identity Management LDAP connections

This example uses a dedicated service account called redhat that has bind, read, and search permissions on the user and group entries.

  • 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
  • Last name attribute: sn
  • Email address attribute: mail

Example 7.3. Example settings for POSIX LDAP connections

This example uses a dedicated service account called redhat that has bind, read, and search permissions on the user and group entries.

  • 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
  • Last name attribute: sn
  • Email address attribute: mail

7.4. Example LDAP filters

Example 7.4. Example LDAP filters for allowing specific users to login

You are using the following LDAP directory structure:

DC=Domain,DC=Example
   |
   |----- CN=Users
         |
         |----- CN=Group1
         |----- CN=Group2
         |----- CN=User1
         |----- CN=User2
         |----- CN=User3
Copy to Clipboard Toggle word wrap

Group membership is defined as follows:

  • Group1 includes users User1 and User3
  • Group2 includes users User2 and User3

For example, you can define the following search filters:

Expand
Search result (users)Filter

User1

(distinguishedName=cn=User1,cn=Users,dc=domain,dc=example)

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))

User1, User2, User3

(memberOf:1.2.840.113556.1.4.1941:=cn=Users,dc=domain,dc=example)

Because group Users is a nested group that contains groups Group1 and Group2, the filter must include memberOf:1.2.840.113556.1.4.1941:= before the nested group name. This enables you to filter all users from the nested group.

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:

# grep 'puppet\|apache\|foreman\|foreman-proxy' /etc/passwd /etc/group
Copy to Clipboard Toggle word wrap

Chapter 9. Configuring external user groups

Satellite does not associate external users with their user group automatically. You must create a user group with the same name as in the external source on Satellite. Members of the external user group then automatically become members of the Satellite user group and receive the associated permissions.

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

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.

Prerequisites

  • If you use an LDAP server, configure Satellite to use LDAP authentication. For more information, see Chapter 7, Configuring an LDAP server as an external identity provider for Satellite.

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

  • If you use a Identity Management or AD server, configure Satellite to use Identity Management or AD authentication. For more information, see Configuring authentication for Red Hat Satellite users.
  • Ensure that at least one external user authenticates for the first time.
  • Retain a copy of the external group names you want to use. To find the group membership of external users, enter the following command:

    # id username
    Copy to Clipboard Toggle word wrap

Procedure

  1. In the Satellite web UI, navigate to Administer > User Groups, and click Create User Group.
  2. Specify the name of the new user group. Do not select any users to avoid adding users automatically when you refresh the external user group.
  3. Click the Roles tab and select the roles you want to assign to the user group. Alternatively, select the Administrator checkbox to assign all available permissions.
  4. Click the External groups tab, then click Add external user group, and select an authentication source from the Auth source drop-down menu.

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

  5. Click Submit.

To set the LDAP source to synchronize user group membership automatically on user login, in the Auth Source page, select the Usergroup Sync option. If this option is not selected, LDAP user groups are refreshed automatically through a scheduled 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.

Use this procedure to refresh the LDAP source manually.

Procedure

  1. In the Satellite web UI, navigate to Administer > Usergroups and select a user group.
  2. On the External Groups tab, click Refresh to the right of the required user group.

CLI procedure

  • Enter the following command:

    # foreman-rake ldap:refresh_usergroups
    Copy to Clipboard Toggle word wrap

External user groups based on Identity Management 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 web UI, such changes are overwritten on the next group refresh.

Legal Notice

Copyright © 2025 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.
Back to top
Red Hat logoGithubredditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust. Explore our recent updates.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

Theme

© 2025 Red Hat