Configuring authentication for Red Hat Satellite users
Configure authentication for Satellite users and enable authentication features such as SSO, OTP, or 2FA
Abstract
Providing feedback on Red Hat documentation Copy linkLink copied to clipboard!
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
- Ensure you have registered a Red Hat account.
Procedure
- Click the following link: Create Issue. If Jira displays a login error, log in and proceed after you are redirected to the form.
- 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.
- Click Create.
Chapter 1. Overview of authentication methods in Satellite Copy linkLink copied to clipboard!
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.
| Username and password | Single 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 Copy linkLink copied to clipboard!
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 Copy linkLink copied to clipboard!
Use the web user interface to log in to Satellite for further configuration.
Prerequisites
- Ensure that the Katello root CA certificate is installed in your browser. For more information, see Section 2.2, “Importing the Katello root CA certificate”.
Procedure
Access Satellite Server using a web browser pointed to the fully qualified domain name:
https://satellite.example.com/
https://satellite.example.com/Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 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
- If you have problems logging in, you can reset the password. For more information, see Section 2.3, “Resetting the administrative user password”.
2.2. Importing the Katello root CA certificate Copy linkLink copied to clipboard!
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
Identify the fully qualified domain name of your Satellite Server:
hostname -f
# hostname -fCopy to Clipboard Copied! Toggle word wrap Toggle overflow Access the
pubdirectory on your Satellite Server using a web browser pointed to the fully qualified domain name:https://satellite.example.com/pub
https://satellite.example.com/pubCopy to Clipboard Copied! Toggle word wrap Toggle overflow - 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.
-
Select
katello-server-ca.crt. - Import the certificate into your browser as a certificate authority and trust it to identify websites.
CLI procedure
From the Satellite CLI, copy the
katello-server-ca.crtfile to the machine you use to access the Satellite web UI:scp /var/www/html/pub/katello-server-ca.crt username@hostname:remotefile
# scp /var/www/html/pub/katello-server-ca.crt username@hostname:remotefileCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
In the browser, import the
katello-server-ca.crtcertificate as a certificate authority and trust it to identify websites.
2.3. Resetting the administrative user password Copy linkLink copied to clipboard!
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
- Log in to the base operating system where Satellite Server is installed.
Enter the following command to reset the password:
foreman-rake permissions:reset
# foreman-rake permissions:reset Reset to user: admin, password: qwJxBptxb7Gfcjj5Copy to Clipboard Copied! Toggle word wrap Toggle overflow - Use this password to reset the password in the Satellite web UI.
Edit the
~/.hammer/cli.modules.d/foreman.ymlfile on Satellite Server to add the new password:vi ~/.hammer/cli.modules.d/foreman.yml
# vi ~/.hammer/cli.modules.d/foreman.ymlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
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
- Log in to the base operating system where Satellite Server is installed.
To set the password, enter the following command:
foreman-rake permissions:reset password=new_password
# foreman-rake permissions:reset password=new_passwordCopy to Clipboard Copied! Toggle word wrap Toggle overflow Edit the
~/.hammer/cli.modules.d/foreman.ymlfile on Satellite Server to add the new password:vi ~/.hammer/cli.modules.d/foreman.yml
# vi ~/.hammer/cli.modules.d/foreman.ymlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
Unless you update the ~/.hammer/cli.modules.d/foreman.yml file, you cannot use the new password with Hammer CLI.
2.4. Setting a custom message on the Satellite web UI login page Copy linkLink copied to clipboard!
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
- In the Satellite web UI, navigate to Administer > Settings, and click the General tab.
- Enter your custom message in the Login page footer text field.
- Click Submit.
Verification
- Log out of the Satellite web UI and verify that the custom message is now displayed on the login page.
Chapter 3. Configuring Kerberos SSO with Identity Management in Satellite Copy linkLink copied to clipboard!
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.
3.1. Enrolling Satellite Server in a Identity Management domain Copy linkLink copied to clipboard!
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
On the Identity Management server:
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.
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.
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-installutility.For more information, see Red Hat Enterprise Linux 9 Installing Identity Management.
NoteTo install packages on your Satellite Server, use the
satellite-installerutility.
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
adminuser that Identity Management creates by default:id admin
$ id adminCopy to Clipboard Copied! Toggle word wrap Toggle overflow
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:
Authenticate as the Identity Management admin user:
kinit admin
# kinit adminCopy to Clipboard Copied! Toggle word wrap Toggle overflow Optional: Verify that you have authenticated successfully:
klist
# klistCopy to Clipboard Copied! Toggle word wrap Toggle overflow Create a host entry from the command line. Specify that you want to use a random password for the enrollment.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Enable access to the keytab file by creating a service principal for your Satellite Server:
ipa service-add HTTP/satellite-server.example.com
# ipa service-add HTTP/satellite-server.example.comCopy to Clipboard Copied! Toggle word wrap Toggle overflow
On the Satellite Server system, a user with Satellite administrative privileges enrolls the system into the Identity Management domain:
Install the Identity Management client packages:
satellite-maintain packages install ipa-client
# satellite-maintain packages install ipa-clientCopy to Clipboard Copied! Toggle word wrap Toggle overflow Configure the Satellite Server system a client in Identity Management by using the random password produced by
ipa host-addin a previous step:ipa-client-install --password 'W5YpARl=7M.n'
# ipa-client-install --password 'W5YpARl=7M.n'Copy to Clipboard Copied! Toggle word wrap Toggle overflow Verify that you are able to resolve the Identity Management
adminuser from your Satellite Server:id admin
$ id adminCopy to Clipboard Copied! Toggle word wrap Toggle overflow
3.2. Configuring the Identity Management authentication source on Satellite Server Copy linkLink copied to clipboard!
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
Enable access for your preferred login method:
To enable access to the Satellite web UI only:
satellite-installer \ --foreman-ipa-authentication true
# satellite-installer \ --foreman-ipa-authentication trueCopy to Clipboard Copied! Toggle word wrap Toggle overflow 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
# satellite-installer \ --foreman-ipa-authentication-api true \ --foreman-ipa-authentication trueCopy to Clipboard Copied! Toggle word wrap Toggle overflow WarningEnabling access to both the Satellite web UI and the Satellite API poses a security risk. After the Identity Management user enters
kinitto 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
# satellite-installer --reset-foreman-ipa-authentication-apiCopy to Clipboard Copied! Toggle word wrap Toggle overflow
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_orderoption in the[domain/idm-server.example.com]section of the/etc/sssd/sssd.conffile:[domain/idm-server.example.com] lookup_family_order = ipv6_only
[domain/idm-server.example.com] lookup_family_order = ipv6_onlyCopy to Clipboard Copied! Toggle word wrap Toggle overflow 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_orderto translate the DNS name correctly. Without the option, IdM users are unable to usekinitto authenticate to Satellite.
Verification
- Log in to Satellite web UI by entering the credentials of a user defined in Identity Management.
3.3. Configuring host-based access control for Identity Management users logging in to Satellite Copy linkLink copied to clipboard!
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
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.
- Create a HBAC service for Satellite Server.
Create a new HBAC rule to define the required access control. Add the following Identity Management entities to the HBAC rule:
- The HBAC service for Satellite Server
- The Satellite Server host
- The users or user groups to whom you want to grant access
-
Make sure the default Identity Management
allow_allrule is disabled. For information about how to disableallow_allwithout disrupting other services, see the How to configure HBAC rules in IdM article on the Red Hat Customer Portal.
On your Satellite Server, load the host-based access control rules from Identity Management:
satellite-installer --foreman-pam-service foreman-prod
# satellite-installer --foreman-pam-service foreman-prodCopy to Clipboard Copied! Toggle word wrap Toggle overflow
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:
Authenticate as the user with privileges required to configure HBAC rules:
kinit admin
$ kinit adminCopy to Clipboard Copied! Toggle word wrap Toggle overflow Optional: Verify that you have authenticated successfully:
klist
$ klistCopy to Clipboard Copied! Toggle word wrap Toggle overflow Create a new HBAC service named
satellite-prod:ipa hbacsvc-add satellite-prod
$ ipa hbacsvc-add satellite-prodCopy to Clipboard Copied! Toggle word wrap Toggle overflow Create a new HBAC rule:
ipa hbacrule-add allow-satellite-prod
$ ipa hbacrule-add allow-satellite-prodCopy to Clipboard Copied! Toggle word wrap Toggle overflow Add the following Identity Management entities to the HBAC rule:
The
satellite-prodHBAC service:ipa hbacrule-add-service allow-satellite-prod --hbacsvcs=satellite-prod
$ ipa hbacrule-add-service allow-satellite-prod --hbacsvcs=satellite-prodCopy to Clipboard Copied! Toggle word wrap Toggle overflow The Satellite Server host:
ipa hbacrule-add-host allow-satellite-prod --hosts=satellite.example.com
$ ipa hbacrule-add-host allow-satellite-prod --hosts=satellite.example.comCopy to Clipboard Copied! Toggle word wrap Toggle overflow The users or user groups to whom you want to grant access:
ipa hbacrule-add-user allow-satellite-prod --user=ipa-user
$ ipa hbacrule-add-user allow-satellite-prod --user=ipa-userCopy to Clipboard Copied! Toggle word wrap Toggle overflow
Optional: Verify the status of the rule:
ipa hbacrule-find satellite-prod ipa hbactest --user=ipa-user --host=satellite.example.com --service=satellite-prod
$ ipa hbacrule-find satellite-prod $ ipa hbactest --user=ipa-user --host=satellite.example.com --service=satellite-prodCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
Disable the default
allow_allrule:
ipa hbacrule-disable allow_all
$ ipa hbacrule-disable allow_all
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
# satellite-installer --foreman-pam-service satellite-prod
3.4. Configuring Hammer CLI to accept Identity Management credentials Copy linkLink copied to clipboard!
Configure the Satellite Hammer CLI tool to use Identity Management to authenticate users.
Prerequisites
- You have enabled Identity Management access to the Satellite API. For more information, see Section 3.2, “Configuring the Identity Management authentication source on Satellite Server”.
Procedure
Open the
~/.hammer/cli.modules.d/foreman.ymlfile on your Satellite Server and update the list offoremanparameters:To enforce session usage, enable
:use_sessions:::foreman: :use_sessions: true
:foreman: :use_sessions: trueCopy to Clipboard Copied! Toggle word wrap Toggle overflow 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
:foreman: :default_auth_type: 'Negotiate_Auth' :use_sessions: trueCopy to Clipboard Copied! Toggle word wrap Toggle overflow With this configuration, Hammer will negotiate authentication automatically when you enter the first
hammercommand.
3.5. Logging in to Hammer CLI with Identity Management credentials Copy linkLink copied to clipboard!
Authenticate to the Satellite Hammer CLI with your Identity Management username and password.
Prerequisites
- You have configured Hammer CLI to accept Identity Management credentials. For more information, see Configuring Hammer CLI to accept Identity Management credentials in Installing Satellite Server in a connected network environment.
Procedure
Authenticate as a user defined in Identity Management to obtain a Kerberos ticket-granting ticket (TGT):
kinit Identity_Management_user
$ kinit Identity_Management_userCopy to Clipboard Copied! Toggle word wrap Toggle overflow WarningIf 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.
If Hammer is not configured to negotiate authentication, initiate an authentication session manually:
hammer auth login negotiate
$ hammer auth login negotiateCopy to Clipboard Copied! Toggle word wrap Toggle overflow
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
hammercommand to check that the system does not ask you to authenticate. For example:hammer host list
$ hammer host listCopy to Clipboard Copied! Toggle word wrap Toggle overflow
Additional resources
-
Run
hammer auth --helpto view all Hammer CLI authentication configuration options. - For more information about authenticating with Hammer, see Hammer authentication in Using the Hammer CLI tool.
3.6. Logging in to the Satellite web UI with Identity Management credentials in Mozilla Firefox Copy linkLink copied to clipboard!
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
- You have Identity Management authentication configured in your Satellite environment. For more information, see Chapter 3, Configuring Kerberos SSO with Identity Management in Satellite.
- The host on which you are using Mozilla Firefox is a client in the Identity Management domain.
- Your Mozilla Firefox is configured for Single Sign-On (SSO). For more information, see Configuring Firefox to use Kerberos for single sign-on in Configuring authentication and authorization in Red Hat Enterprise Linux 9.
Procedure
Obtain the Kerberos ticket granting ticket (TGT):
kinit user
$ kinit user Password for user@EXAMPLE.COM:Copy to Clipboard Copied! Toggle word wrap Toggle overflow - In Mozilla Firefox, go to the URL of your Satellite Server.
- You are logged in automatically.
Alternatively:
- In your browser address bar, enter the URL of your Satellite Server.
- Enter your username and password.
3.7. Logging in to the Satellite web UI with Identity Management credentials in Chrome Copy linkLink copied to clipboard!
You can use Chrome to log in to the Satellite web UI with your Identity Management credentials.
Use the latest stable Chrome browser.
Prerequisites
- You have Identity Management authentication configured in your Satellite environment. For more information, see Chapter 3, Configuring Kerberos SSO with Identity Management in Satellite.
- The host on which you are using Chrome is a client in the Identity Management domain.
Procedure
Enable the Chrome browser to use Kerberos authentication:
google-chrome --auth-server-whitelist="*.example.com" --auth-negotiate-delegate-whitelist="*.example.com"
$ google-chrome --auth-server-whitelist="*.example.com" --auth-negotiate-delegate-whitelist="*.example.com"Copy to Clipboard Copied! Toggle word wrap Toggle overflow NoteInstead of allowlisting the whole domain, you can also allowlist a specific Satellite Server.
Obtain the Kerberos ticket-granting ticket (TGT):
kinit user
$ kinit user Password for user@EXAMPLE.COM:Copy to Clipboard Copied! Toggle word wrap Toggle overflow - In Chrome, go to the URL of your Satellite Server.
- You are logged in automatically.
Alternatively:
- In your browser address bar, enter the URL of your Satellite Server.
- Enter your username and password.
3.8. Configuring a cross-forest trust between Identity Management and Active Directory for Satellite Copy linkLink copied to clipboard!
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
- An existing Identity Management server with a cross-forest trust with AD established. For more information, see Red Hat Enterprise Linux 9 Installing trust between IdM and AD.
Procedure
On your Identity Management server:
Enable HBAC:
- Create an external group and add the AD group to it.
- Add the new external group to a POSIX group.
- 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:
Add the AD user attributes to the nss and domain sections in
/etc/sssd/sssd.conf. For example:Copy to Clipboard Copied! Toggle word wrap Toggle overflow Clear the SSSD cache:
Stop SSSD:
systemctl stop sssd
# systemctl stop sssdCopy to Clipboard Copied! Toggle word wrap Toggle overflow Clear the cache:
sss_cache -E
# sss_cache -ECopy to Clipboard Copied! Toggle word wrap Toggle overflow Start SSSD:
systemctl start sssd
# systemctl start sssdCopy to Clipboard Copied! Toggle word wrap Toggle overflow
Verify the AD attributes value by using the
dbus-sendcommand 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
# 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,lastnameCopy to Clipboard Copied! Toggle word wrap Toggle overflow
Chapter 4. Configuring SSO and 2FA with Red Hat Single Sign-On in Satellite Copy linkLink copied to clipboard!
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.
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
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.
4.1. Prerequisites for configuring Satellite with Red Hat Single Sign-On authentication Copy linkLink copied to clipboard!
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
# satellite-maintain packages install mod_auth_openidc keycloak-httpd-client-install python3-lxmlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
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.
4.2. Registering Satellite as a client of Red Hat Single Sign-On Copy linkLink copied to clipboard!
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:
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:
Create a client for Satellite. Use
foreman-openidcas the application name.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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"
# satellite-installer --foreman-keycloak true \ --foreman-keycloak-app-name "foreman-openidc" \ --foreman-keycloak-realm "Satellite_Realm"Copy to Clipboard Copied! Toggle word wrap Toggle overflow
If you want users to authenticate by using the Hammer CLI:
Create a client for Satellite. Use
hammer-openidcas the application name.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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"
# satellite-installer --foreman-keycloak true \ --foreman-keycloak-app-name "hammer-openidc" \ --foreman-keycloak-realm "Satellite_Realm"Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Restart the
httpdservice:systemctl restart httpd
# systemctl restart httpdCopy to Clipboard Copied! Toggle word wrap Toggle overflow
4.3. Configuring the Satellite client in Red Hat Single Sign-On Copy linkLink copied to clipboard!
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:
- Go to the realm created for Satellite users. Navigate to Clients and click the Satellite client.
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.
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
-
You will see a pre-defined URI:
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
-
You will see a pre-defined URI:
- Click Save.
On the Mappers tab, click Create to add an audience mapper.
- From the Mapper Type list, select Audience.
- From the Included Client Audience list, select the Satellite client.
- Click Save.
On the Mappers tab, click Create to add a group mapper so that you can specify authorization in Satellite based on group membership.
- From the Mapper Type list, select Group Membership.
- In the Token Claim Name field, enter groups.
-
Set the Full group path setting to
OFF.
- Click Save.
Additional resources
- For more information about configuring Red Hat Single Sign-On clients, see Red Hat Single Sign-On Server Administration Guide.
4.4. Configuring a Satellite client to provide Satellite web UI authentication with Red Hat Single Sign-On Copy linkLink copied to clipboard!
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
- Ensure that the Access Type setting in the Satellite client in the Red Hat Single Sign-On web UI is set to confidential. For more information, see Section 4.3, “Configuring the Satellite client in Red Hat Single Sign-On”.
Procedure
In the Satellite web UI:
- Navigate to Administer > Settings.
On the Authentication tab, configure the following settings:
-
Authorize login delegation: Set to
Yes. -
Authorize login delegation auth source user autocreate: Set to
External. -
Login delegation logout URL: Set to
https://satellite.example.com/users/extlogout. -
OIDC Algorithm: For example, set to
RS256. - OIDC Audience: Set to the client ID for Red Hat Single Sign-On.
-
OIDC Issuer: Set to
https://rhsso.example.com/auth/realms/Satellite_Realm. -
OIDC JWKs URL: Set to
https://rhsso.example.com/auth/realms/Satellite_Realm/protocol/openid-connect/certs.
-
Authorize login delegation: Set to
Navigate to Administer > Authentication Sources.
- From the External menu, select Edit.
- On the Locations tab, add the locations that you want to be able to use the Red Hat Single Sign-On authentication source.
- On the Organizations tab, add the organizations that you want to be able to use the Red Hat Single Sign-On authentication source.
- Click Submit.
4.5. Configuring a Satellite client to provide Hammer CLI authentication with Red Hat Single Sign-On Copy linkLink copied to clipboard!
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:
Set the login delegation to
trueso that users can authenticate using the Open IDC protocol:hammer settings set --name authorize_login_delegation --value true
$ hammer settings set --name authorize_login_delegation --value trueCopy to Clipboard Copied! Toggle word wrap Toggle overflow Set the login delegation logout URL:
hammer settings set --name login_delegation_logout_url \ --value https://satellite.example.com/users/extlogout
$ hammer settings set --name login_delegation_logout_url \ --value https://satellite.example.com/users/extlogoutCopy to Clipboard Copied! Toggle word wrap Toggle overflow Set the algorithm for encoding: For example, to use the
RS256algorithm:hammer settings set --name oidc_algorithm --value 'RS256'
$ hammer settings set --name oidc_algorithm --value 'RS256'Copy to Clipboard Copied! Toggle word wrap Toggle overflow Add the value for the Hammer client in the Open IDC audience:
hammer settings set --name oidc_audience \ --value "['satellite.example.com-hammer-openidc']"
$ hammer settings set --name oidc_audience \ --value "['satellite.example.com-hammer-openidc']"Copy to Clipboard Copied! Toggle word wrap Toggle overflow Set the value for the Open IDC issuer:
hammer settings set --name oidc_issuer \ --value "https://rhsso.example.com/auth/realms/Satellite_Realm"
$ hammer settings set --name oidc_issuer \ --value "https://rhsso.example.com/auth/realms/Satellite_Realm"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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"
$ hammer settings set --name oidc_jwks_url \ --value "https://rhsso.example.com/auth/realms/Satellite_Realm/protocol/openid-connect/certs"Copy to Clipboard Copied! Toggle word wrap Toggle overflow Retrieve the ID of the Red Hat Single Sign-On authentication source:
hammer auth-source external list
$ hammer auth-source external listCopy to Clipboard Copied! Toggle word wrap Toggle overflow 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
$ hammer auth-source external update \ --id My_Authentication_Source_ID \ --location-ids My_Location_ID \ --organization-ids My_Organization_IDCopy to Clipboard Copied! Toggle word wrap Toggle overflow
4.6. Configuring Satellite with Red Hat Single Sign-On for TOTP authentication Copy linkLink copied to clipboard!
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
- In the Red Hat Single Sign-On web UI, navigate to the Satellite realm.
- Navigate to Authentication.
- On the Policies tab, click the OTP Policy tab. Ensure that the Supported Applications field includes FreeOTP or Google Authenticator.
- Configure the OTP settings to suit your requirements.
- On Required Actions tab, enable the Set as default action setting for the Configure OTP action.
Additional resources
- For more information, see Red Hat Single Sign-On Server Administration Guide or Red Hat build of Keycloak Server Administration Guide.
4.7. Optional: Configuring external group mapping for Red Hat Single Sign-On authentication Copy linkLink copied to clipboard!
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
- In the Satellite web UI, navigate to Administer > User Groups.
Click Create User Group.
- In the Name field, enter a name for the user group. Enter a name that is different from the Active Directory user group name.
- Do not add any users or user groups to the new group in Satellite web UI.
- On the Roles tab, select Administer.
On the External Groups tab, click Add external user group.
- In the Name field, enter the name of the Active Directory group.
- From the Auth Source drop-down menu, select EXTERNAL.
- Click Submit.
4.8. Logging in to Satellite configured with Red Hat Single Sign-On as an authentication source Copy linkLink copied to clipboard!
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.comand enter your credentials.
To authenticate to the Satellite web UI by using Red Hat Single Sign-On TOTP:
- In your browser, log in to Satellite. Satellite redirects you to the Red Hat Single Sign-On login screen.
- Enter your username and password, and click Log In.
- 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:
Ensure that Hammer is configured to enforce session usage in
~/.hammer/cli.modules.d/foreman.yml::foreman: :use_sessions: true
:foreman: :use_sessions: trueCopy to Clipboard Copied! Toggle word wrap Toggle overflow 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
$ 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:oobCopy to Clipboard Copied! Toggle word wrap Toggle overflow
To authenticate to the Satellite CLI with Hammer by using Red Hat Single Sign-On TOTP:
Ensure that Hammer is configured to enforce session usage in
~/.hammer/cli.modules.d/foreman.yml::foreman: :use_sessions: true
:foreman: :use_sessions: trueCopy to Clipboard Copied! Toggle word wrap Toggle overflow Initiate an authentication session by using
--two-factorwithhammer auth login oauth:Copy to Clipboard Copied! Toggle word wrap Toggle overflow - You will be prompted to enter a success code. To retrieve the success code, navigate to the URL that the command returns.
- Enter the success code in CLI.
Chapter 5. Configuring SSO and 2FA with Red Hat build of Keycloak in Satellite Copy linkLink copied to clipboard!
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
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.
5.1. Prerequisites for configuring Satellite with Red Hat build of Keycloak authentication Copy linkLink copied to clipboard!
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
# satellite-maintain packages install mod_auth_openidc keycloak-httpd-client-install python3-lxmlCopy to Clipboard Copied! Toggle word wrap Toggle overflow Check which
keycloak-httpd-client-installversion is installed:rpm --query keycloak-httpd-client-install
# rpm --query keycloak-httpd-client-installCopy to Clipboard Copied! Toggle word wrap Toggle overflow
On the Red Hat build of Keycloak side, ensure you meet the following requirements:
If
keycloak-httpd-client-installversion 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=/authcontext path. To access a Red Hat build of Keycloak server initialized with--http-relative-path=/authfrom its web UI, go tohttps://rhbk.example.com:8443/auth. -
If you want to use a different context path, make manual adjustments after the initialization with
/author configure theforeman-openidc_oidc_keycloak_Foreman_Realm.conffile of the HTTPd service manually. For more information about configuring a different context path, see the Red Hat build of Keycloak Administration Guide.
-
You can use a Red Hat build of Keycloak server that has been initialized with the
-
If
keycloak-httpd-client-installversion 1.3 or later is installed, your Red Hat build of Keycloak server does not need to be initialized with the--http-relative-path=/authcontext 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.
5.2. Registering Satellite as a client of Red Hat build of Keycloak Copy linkLink copied to clipboard!
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:
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:
Create a client for Satellite. Use
foreman-openidcas the application name.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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"
# satellite-installer --foreman-keycloak true \ --foreman-keycloak-app-name "foreman-openidc" \ --foreman-keycloak-realm "Satellite_Realm"Copy to Clipboard Copied! Toggle word wrap Toggle overflow
If you want users to authenticate by using the Hammer CLI:
Create a client for Satellite. Use
hammer-openidcas the application name.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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"
# satellite-installer --foreman-keycloak true \ --foreman-keycloak-app-name "hammer-openidc" \ --foreman-keycloak-realm "Satellite_Realm"Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Restart the
httpdservice:systemctl restart httpd
# systemctl restart httpdCopy to Clipboard Copied! Toggle word wrap Toggle overflow
5.3. Configuring the Satellite client in Red Hat build of Keycloak Copy linkLink copied to clipboard!
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:
- Go to the realm created for Satellite users.
- Navigate to Clients and click the Satellite client.
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:
- Enable Client 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:
- Ensure Client authentication is disabled.
-
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
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.On the Mappers tab for
client-name-dedicated, add a new mapper by configuration. Select the Audience mapper type.- From the Included Client Audience list, select the Satellite client.
- Enable Add to ID token.
- Click Save.
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.
- In the Token Claim Name field, enter groups.
- Disable Full group path.
- Click Save.
Additional resources
- For more information about configuring Red Hat build of Keycloak clients, see Red Hat build of Keycloak Server Administration Guide.
5.4. Configuring a Satellite client to provide Satellite web UI authentication with Red Hat build of Keycloak Copy linkLink copied to clipboard!
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
- Ensure that the Client authentication setting in the Satellite client in the Red Hat build of Keycloak web UI is enabled. For more information, see Section 5.3, “Configuring the Satellite client in Red Hat build of Keycloak”.
Procedure
In the Satellite web UI:
- Navigate to Administer > Settings.
On the Authentication tab, configure the following settings:
-
Authorize login delegation: Set to
Yes. -
Authorize login delegation auth source user autocreate: Set to
External. -
Login delegation logout URL: Set to
https://satellite.example.com/users/extlogout. -
OIDC Algorithm: For example, set to
RS256. - OIDC Audience: Set to the client ID for Red Hat build of Keycloak.
OIDC Issuer:
-
Set to
https://rhbk.example.com:8443/realms/Satellite_Realmif you initialized your Red Hat build of Keycloak server without the--http-relative-path=/authcontext path. -
Set to
https://rhbk.example.com:8443/auth/realms/Satellite_Realmif you initialized your Red Hat build of Keycloak server with the--http-relative-path=/authcontext path.
-
Set to
OIDC JWKs URL:
-
Set to
https://rhbk.example.com:8443/realms/Satellite_Realm/protocol/openid-connect/certsif you initialized your Red Hat build of Keycloak server without the--http-relative-path=/authcontext path. -
Set to
https://rhbk.example.com:8443/auth/realms/Satellite_Realm/protocol/openid-connect/certsif you initialized your Red Hat build of Keycloak server with the--http-relative-path=/authcontext path.
-
Set to
-
Authorize login delegation: Set to
Navigate to Administer > Authentication Sources.
- From the External menu, select Edit.
- On the Locations tab, add the locations that you want to be able to use the Red Hat build of Keycloak authentication source.
- On the Organizations tab, add the organizations that you want to be able to use the Red Hat build of Keycloak authentication source.
- Click Submit.
5.5. Configuring a Satellite client to provide Hammer CLI authentication with Red Hat build of Keycloak Copy linkLink copied to clipboard!
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=/authcontext 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=/authcontext 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:
Set the login delegation to
trueso that users can authenticate using the Open IDC protocol:hammer settings set --name authorize_login_delegation --value true
$ hammer settings set --name authorize_login_delegation --value trueCopy to Clipboard Copied! Toggle word wrap Toggle overflow Set the login delegation logout URL:
hammer settings set --name login_delegation_logout_url \ --value https://satellite.example.com/users/extlogout
$ hammer settings set --name login_delegation_logout_url \ --value https://satellite.example.com/users/extlogoutCopy to Clipboard Copied! Toggle word wrap Toggle overflow Set the algorithm for encoding: For example, to use the
RS256algorithm:hammer settings set --name oidc_algorithm --value 'RS256'
$ hammer settings set --name oidc_algorithm --value 'RS256'Copy to Clipboard Copied! Toggle word wrap Toggle overflow Add the value for the Hammer client in the Open IDC audience:
hammer settings set --name oidc_audience \ --value "['satellite.example.com-hammer-openidc']"
$ hammer settings set --name oidc_audience \ --value "['satellite.example.com-hammer-openidc']"Copy to Clipboard Copied! Toggle word wrap Toggle overflow Set the value for the Open IDC issuer:
If you initialized your Red Hat build of Keycloak server without the
--http-relative-path=/authcontext path:hammer settings set --name oidc_issuer \ --value "https://rhbk.example.com:8443/realms/Satellite_Realm"
$ hammer settings set --name oidc_issuer \ --value "https://rhbk.example.com:8443/realms/Satellite_Realm"Copy to Clipboard Copied! Toggle word wrap Toggle overflow If you initialized your Red Hat build of Keycloak server with the
--http-relative-path=/authcontext path:hammer settings set --name oidc_issuer \ --value "https://rhbk.example.com:8443/auth/realms/Satellite_Realm"
$ hammer settings set --name oidc_issuer \ --value "https://rhbk.example.com:8443/auth/realms/Satellite_Realm"Copy to Clipboard Copied! Toggle word wrap Toggle overflow
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=/authcontext path:hammer settings set --name oidc_jwks_url \ --value "https://rhbk.example.com:8443/realms/Satellite_Realm/protocol/openid-connect/certs"
$ hammer settings set --name oidc_jwks_url \ --value "https://rhbk.example.com:8443/realms/Satellite_Realm/protocol/openid-connect/certs"Copy to Clipboard Copied! Toggle word wrap Toggle overflow If you initialized your Red Hat build of Keycloak server with the
--http-relative-path=/authcontext path:hammer settings set --name oidc_jwks_url \ --value "https://rhbk.example.com:8443/auth/realms/Satellite_Realm/protocol/openid-connect/certs"
$ hammer settings set --name oidc_jwks_url \ --value "https://rhbk.example.com:8443/auth/realms/Satellite_Realm/protocol/openid-connect/certs"Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Retrieve the ID of the Red Hat build of Keycloak authentication source:
hammer auth-source external list
$ hammer auth-source external listCopy to Clipboard Copied! Toggle word wrap Toggle overflow 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
$ hammer auth-source external update \ --id My_Authentication_Source_ID \ --location-ids My_Location_ID \ --organization-ids My_Organization_IDCopy to Clipboard Copied! Toggle word wrap Toggle overflow
5.6. Configuring Satellite with Red Hat build of Keycloak for TOTP authentication Copy linkLink copied to clipboard!
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
- In the Red Hat build of Keycloak web UI, navigate to the Satellite realm.
- Navigate to Authentication.
- On the Policies tab, click the OTP Policy tab. Ensure that the Supported Applications field includes FreeOTP or Google Authenticator.
- Configure the OTP settings to suit your requirements.
- On Required Actions tab, enable the Set as default action setting for the Configure OTP action.
Additional resources
- For more information, see Red Hat Single Sign-On Server Administration Guide or Red Hat build of Keycloak Server Administration Guide.
5.7. Optional: Configuring external group mapping for Red Hat build of Keycloak authentication Copy linkLink copied to clipboard!
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
- In the Satellite web UI, navigate to Administer > User Groups.
Click Create User Group.
- In the Name field, enter a name for the user group. Enter a name that is different from the Active Directory user group name.
- Do not add any users or user groups to the new group in Satellite web UI.
- On the Roles tab, select Administer.
On the External Groups tab, click Add external user group.
- In the Name field, enter the name of the Active Directory group.
- From the Auth Source drop-down menu, select EXTERNAL.
- Click Submit.
5.8. Logging in to Satellite configured with Red Hat build of Keycloak as an authentication source Copy linkLink copied to clipboard!
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.comand enter your credentials.
To authenticate to the Satellite web UI by using Red Hat build of Keycloak TOTP:
- In your browser, log in to Satellite. Satellite redirects you to the Red Hat build of Keycloak login screen.
- Enter your username and password, and click Log In.
- 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:
Ensure that Hammer is configured to enforce session usage in
~/.hammer/cli.modules.d/foreman.yml::foreman: :use_sessions: true
:foreman: :use_sessions: trueCopy to Clipboard Copied! Toggle word wrap Toggle overflow Initiate an authentication session with
hammer auth login oauth:If you initialized your Red Hat build of Keycloak server without the
--http-relative-path=/authcontext 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
$ 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:oobCopy to Clipboard Copied! Toggle word wrap Toggle overflow If you initialized your Red Hat build of Keycloak server with the
--http-relative-path=/authcontext 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
$ 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:oobCopy to Clipboard Copied! Toggle word wrap Toggle overflow
To authenticate to the Satellite CLI with Hammer by using Red Hat build of Keycloak TOTP:
Ensure that Hammer is configured to enforce session usage in
~/.hammer/cli.modules.d/foreman.yml::foreman: :use_sessions: true
:foreman: :use_sessions: trueCopy to Clipboard Copied! Toggle word wrap Toggle overflow Initiate an authentication session by using
--two-factorwithhammer auth login oauth:Copy to Clipboard Copied! Toggle word wrap Toggle overflow - You will be prompted to enter a success code. To retrieve the success code, navigate to the URL that the command returns.
- Enter the success code in CLI.
Chapter 6. Configuring Kerberos SSO for Active Directory users in Satellite Copy linkLink copied to clipboard!
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
You can also connect your Satellite deployment to AD in the following ways:
- By using indirect AD integration. With indirect integration, your Satellite Server is connected to a Identity Management server which is then connected to AD. For more information, see Chapter 3, Configuring Kerberos SSO with Identity Management in Satellite.
- By attaching the LDAP server of the AD domain as an external authentication source with no single sign-on support. For more information, see Chapter 7, Configuring an LDAP server as an external identity provider for Satellite. For an example configuration, see How to configure Active Directory authentication with TLS on Satellite.
6.1. Configuring the Active Directory authentication source on Satellite Server Copy linkLink copied to clipboard!
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
# satellite-maintain packages install adcli krb5-workstation oddjob-mkhomedir oddjob realmd samba-winbind-clients samba-winbind samba-common-tools samba-winbind-krb5-locator sssdCopy to Clipboard Copied! Toggle word wrap Toggle overflow Specify the required software when joining the AD domain:
realm join AD.EXAMPLE.COM --membership-software=samba --client-software=sssd
# realm join AD.EXAMPLE.COM --membership-software=samba --client-software=sssdCopy to Clipboard Copied! Toggle word wrap Toggle overflow For more information on direct AD integration, see Connecting RHEL systems directly to AD using Samba Winbind.
Procedure
Define AD realm configuration in a location where satellite-installer expects it:
Create a directory named
/etc/ipa/:mkdir /etc/ipa/
# mkdir /etc/ipa/Copy to Clipboard Copied! Toggle word wrap Toggle overflow Create the
/etc/ipa/default.conffile with the following contents to configure the Kerberos realm for the AD domain:[global] realm = AD.EXAMPLE.COM
[global] realm = AD.EXAMPLE.COMCopy to Clipboard Copied! Toggle word wrap Toggle overflow
Configure the Apache keytab for Kerberos connections:
Update the
/etc/samba/smb.conffile 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
[global] workgroup = AD.EXAMPLE realm = AD.EXAMPLE.COM kerberos method = system keytab security = adsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 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
# KRB5_KTNAME=FILE:/etc/httpd/conf/http.keytab net ads keytab create HTTP -U Administrator -s /etc/samba/smb.confCopy to Clipboard Copied! Toggle word wrap Toggle overflow NoteThe
net ads keytab createcommand was introduced in Samba version 4.21.1. If your system uses an earlier version of Samba, use thenet ads keytab addcommand.
Configure the System Security Services Daemon (SSSD) on your Satellite Server:
Configure the AD access control provider to evaluate and enforce Group Policy Object (GPO) access control rules for the
foremanPAM service. In the[domain/ad.example.com]section of your/etc/sssd/sssd.conffile, set thead_gpo_access_controlandad_gpo_map_serviceoptions as follows:[domain/ad.example.com] ad_gpo_access_control = enforcing ad_gpo_map_service = +foreman
[domain/ad.example.com] ad_gpo_access_control = enforcing ad_gpo_map_service = +foremanCopy to Clipboard Copied! Toggle word wrap Toggle overflow For more information on GPOs, see How SSSD interprets GPO access control rules in Integrating RHEL systems directly with Windows Active Directory (RHEL 9).
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_orderoption in the[domain/ad.example.com]section of the/etc/sssd/sssd.conffile:[domain/ad.example.com] lookup_family_order = ipv6_only
[domain/ad.example.com] lookup_family_order = ipv6_onlyCopy to Clipboard Copied! Toggle word wrap Toggle overflow 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_orderto translate the DNS name correctly. Without the option, AD users are unable to usekinitto authenticate to Satellite.Restart SSSD:
systemctl restart sssd
# systemctl restart sssdCopy to Clipboard Copied! Toggle word wrap Toggle overflow
Enable the authentication source:
satellite-installer --foreman-ipa-authentication true
# satellite-installer --foreman-ipa-authentication trueCopy to Clipboard Copied! Toggle word wrap Toggle overflow
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
$ kinit ad_user@AD.EXAMPLE.COMCopy to Clipboard Copied! Toggle word wrap Toggle overflow Verify user authentication by using your TGT:
curl -k -u : --negotiate https://satellite.example.com/users/extlogin
$ 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 Copied! Toggle word wrap Toggle overflow
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)" } }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 Copied! Toggle word wrap Toggle overflow If you see this error, verify which cipher is used for the connection:
openssl s_client -connect ldap.example.com:636
# openssl s_client -connect ldap.example.com:636Copy to Clipboard Copied! Toggle word wrap Toggle overflow If the
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384cipher is used, disable it on either the Satellite Server side or on the AD side. TheTLS_DHE_RSA_WITH_AES_256_GCM_SHA384cipher 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
-
sssd-ad(5)man page on your system - For information about configuring Mozilla Firefox for Kerberos, see Configuring Firefox to use Kerberos for single sign-on in Red Hat Enterprise Linux 9 Configuring authentication and authorization in RHEL.
Chapter 7. Configuring an LDAP server as an external identity provider for Satellite Copy linkLink copied to clipboard!
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.
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.
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 Copy linkLink copied to clipboard!
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
Obtain the CA certificate from the LDAP Server:
-
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
TLSon Satellite 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 Satellite Server, such as
/tmp/example.crt. You will remove the certificate when finished.The filename extensions
.cerand.crtare only conventions and can refer to DER binary or PEM ASCII format certificates.
-
If you use Active Directory Certificate Services, export the Enterprise PKI CA Certificate using the Base64 encoded X.509 format. See How to configure Active Directory authentication with
Add the LDAP server certificate to the system truststore:
Import the certificate:
cp /tmp/example.crt /etc/pki/ca-trust/source/anchors
# cp /tmp/example.crt /etc/pki/ca-trust/source/anchorsCopy to Clipboard Copied! Toggle word wrap Toggle overflow Update the certificate authority truststore:
update-ca-trust extract
# update-ca-trust extractCopy to Clipboard Copied! Toggle word wrap Toggle overflow
- Delete the downloaded LDAP certificate from the temporary location on your Satellite Server.
Restart Satellite services:
satellite-maintain service restart
# satellite-maintain service restartCopy to Clipboard Copied! Toggle word wrap Toggle overflow
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 Copy linkLink copied to clipboard!
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
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
# setsebool -P nis_enabled onCopy to Clipboard Copied! Toggle word wrap Toggle overflow - In the Satellite web UI, navigate to Administer > Authentication Sources.
- From the LDAP menu, select Create.
On the LDAP server tab, enter the details of your LDAP server.
For TLS encrypted connections, select LDAPS to enable encryption.
On the Account tab, enter the account information and domain name details. For more information, see the following sections:
- On the Attribute mappings tab, map LDAP attributes to Satellite attributes.
- 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.
- 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.
- 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 Copy linkLink copied to clipboard!
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 Copy linkLink copied to clipboard!
Example 7.4. Example LDAP filters for allowing specific users to login
You are using the following LDAP directory structure:
Group membership is defined as follows:
-
Group1includes usersUser1andUser3 -
Group2includes usersUser2andUser3
For example, you can define the following search filters:
| 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.
Chapter 8. Important user and group account information for Active Directory accounts Copy linkLink copied to clipboard!
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
# grep 'puppet\|apache\|foreman\|foreman-proxy' /etc/passwd /etc/group
Chapter 9. Configuring external user groups Copy linkLink copied to clipboard!
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
$loginvariable 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
# id usernameCopy to Clipboard Copied! Toggle word wrap Toggle overflow
Procedure
- In the Satellite web UI, navigate to Administer > User Groups, and click Create User Group.
- 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.
- 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.
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.
- Click Submit.
Chapter 10. Refreshing external user groups for LDAP Copy linkLink copied to clipboard!
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
- In the Satellite web UI, navigate to Administer > Usergroups and select a user group.
- 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
# foreman-rake ldap:refresh_usergroupsCopy to Clipboard Copied! Toggle word wrap Toggle overflow
Chapter 11. Refreshing external user groups for Identity Management or AD Copy linkLink copied to clipboard!
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.