5.3. Managing and Configuring a Cross-forest Trust Environment

5.3.1. User Principal Names in a Trusted Domains Environment

IdM supports the logging in using user principal names (UPN). A UPN is an alternative to the user name to authenticate with, and has the format username@KERBEROS-REALM. In an Active Directory forest it is possible to configure additional UPN suffixes. These enterprise principal names are used to provide alternative logins to the default UPN.

For example, if a company uses the Kerberos realm AD.EXAMPLE.COM, the default UPN for a user is user@ad.example.com. However often a company want instead their users to be able to log in using their email addresses, like user@example.com. In this case the administrator adds an additional UPN suffix example.com to the Active Directory forest and sets the new suffix in the user's account properties.

When you add or remove UPN suffixes in a trusted AD forest, you have to refresh the information for the trusted forest on the IdM master:

[root@ipaserver ~]# ipa trust-fetch-domains
Realm-Name: ad.example.com
-------------------------------
No new trust domains were found
-------------------------------
----------------------------
Number of entries returned 0
----------------------------

Verify that the alternative UPN was fetched, by running:

[root@ipaserver ~]# ipa trust-show
Realm-Name: ad.example.com
  Realm-Name: ad.example.com
  Domain NetBIOS name: AD
  Domain Security Identifier: S-1-5-21-796215754-1239681026-23416912
  Trust direction: Two-way trust
  Trust type: Active Directory domain
  UPN suffixes: example.com

The UPN suffixes for a domain are stored in the multi-value attribute ipaNTAdditionalSuffixes in the cn=trusted_domain_name,cn=ad,cn=trusts,dc=idm,dc=example,dc=com subtree.

5.3.2. IdM Clients in an Active Directory DNS Domain

In some environments with trusts between IdM and Active Directory, you can configure users to access an IdM client using a host name from the Active Directory DNS domain, while the client itself is joined to IdM to benefit from its Linux-focused features.

Important

This is not a recommended configuration and has some limitations. Red Hat recommends to always deploy IdM clients in a DNS zone different from the ones owned by Active Directory and access IdM clients through their IdM host names.

5.3.2.1. Kerberos Single Sign-on to the IdM Client is not Required

For IdM clients set up in the Active Directory DNS domain, only password authentication is available to access resources on this IdM host. To configure the client for this scenario:

To ensure that the System Security Service Daemon (SSSD) on the client can communicate with the IdM servers, install the IdM client with the --domain=IPA_DNS_Domain option:
```
[root@idm-client.ad.example.com ~]# ipa-client-install --domain=idm.example.com
```
This option disables the SRV record auto-detection for the Active Directory DNS domain.
Locate the existing mapping for the Active Directory domain in the [domain_realm] section of the /etc/krb5.conf configuration file:
```
.ad.example.com = IDM.EXAMPLE.COM
ad.example.com = IDM.EXAMPLE.COM
```
Replace both lines with a mapping entry for the Linux clients fully qualified domain name (FQDN) in the Active Directory DNS zone to the IdM realm:
```
idm-client.ad.example.com = IDM.EXAMPLE.COM
```
Replacing the default mapping prevents Kerberos from sending its requests for the Active Directory domain to the IdM Kerberos Distribution Center (KDC). Instead Kerberos uses auto-discovery through SRV DNS records to locate the KDC. Only for the added host idm-client.ad.example.com the IdM KDC is set.

Note

Authenticating to resources on clients that are not within an IdM-owned DNS zone is only possible by using user name and password.

Handling of SSL certificates

SSL-based services require a certificate with dNSName extension records that cover all system host names, because both original (A/AAAA) and CNAME records must be in the certificate. Currently, IdM only issues certificates to host objects in the IdM database.

In the described setup without single sign-on available, IdM already has a host object for the FQDN in the database, and certmonger can request a certificate for this name:

[root@idm-client.ad.example.com ~]# ipa-getcert request -r \
      -f /etc/httpd/alias/server.crt \
      -k /etc/httpd/alias/server.key \
      -N CN=ipa-client.ad.example.com \
      -D ipa-client.ad.example.com \
      -K host/idm-client.ad.example.com@IDM.EXAMPLE.COM \
      -U id-kp-serverAuth

The certmonger service uses the default host key stored in the /etc/krb5.keytab file to authenticate to the IdM Certificate Authority (CA).

5.3.2.2. Kerberos Single Sign-on to the IdM Client is Required

If you require Kerberos single sign-on to access resources on the IdM client, the client must be within the IdM DNS domain, for example idm-client.idm.example.com. You must create a CNAME record idm-client.ad.example.com in the Active Directory DNS domain pointing to the A/AAAA record of the IdM client.

For Kerberos-based application servers, MIT Kerberos supports a method to allow the acceptance of any host-based principal available in the application's keytab. To disable the strict checks on what Kerberos principal was used to target the Kerberos server, set the following option in the [libdefaults] section of the /etc/krb5.conf configuration file:

ignore_acceptor_hostname = true

Handling of SSL certificates

In the described setup without single sign-on available, IdM already has a host object for the FQDN in the database, and certmonger can request a certificate for this name:

Create a new host object:
```
[root@idm-server.idm.example.com ~]# ipa host-add idm-client.ad.example.com --force
```
Use the --force option, because the host name is a CNAME and not an A/AAAA record.

Allow the IdM DNS host name to manage the Active Directory host entry in the IdM database:

[root@idm-server.idm.example.com ~]# ipa host-add-managedby idm-client.ad.example.com \
      --hosts=idm-client.idm.example.com

With this setup, the IdM client can request an SSL certificate with dNSName extension record for its host name within the Active Directory DNS domain:

[root@idm-client.idm.example.com ~]# ipa-getcert request -r \
      -f /etc/httpd/alias/server.crt \
      -k /etc/httpd/alias/server.key \
      -N CN=`hostname --fqdn` \
      -D `hostname --fqdn` \
      -D idm-client.ad.example.com \
      -K host/idm-client.idm.example.com@IDM.EXAMPLE.COM \
      -U id-kp-serverAuth

5.3.3. Creating IdM Groups for Active Directory Users

User groups are required to set access permissions, host-based access control, sudo rules, and other controls on IdM users. These groups are what grant access to IdM domain resources, as well as restricting access.

Both AD users and AD groups can be added directly to IdM user groups. To do that, first add the AD users or groups to a non-POSIX IdM external group and then to a local IdM POSIX group. The POSIX group can then be used for user and role management of the AD users. The principles of handling non-POSIX groups in IdM are described in Section 5.1.3.2, “Active Directory Users and Identity Management Groups”.

Note

It is also possible to add AD user groups as members to IdM external groups. This might make it easier to define policies for Windows users, by keeping the user and group management within the single AD realm.

Optional. Create or select the group in the AD domain to use to manage AD users in the IdM realm. Multiple groups can be used and added to different groups on the IdM side.

Create an external group in the IdM domain for the Active Directory users by adding the --external option to the ipa group-add command. The --external option indicates that this group is intended to contain members from outside the IdM domain. For example:

[root@ipaserver ~]# ipa group-add --desc='AD users external map' ad_users_external --external
-------------------------------
Added group "ad_users_external"
-------------------------------
  Group name: ad_users_external
  Description: AD users external map

Create a new IdM POSIX group or select an existing one for administering the IdM policies. For example, to create a new group:

[root@ipaserver ~]# ipa group-add --desc='AD users' ad_users
----------------------
Added group "ad_users"
----------------------
  Group name: ad_users
  Description: AD users
  GID: 129600004

Add the AD users or groups to the IdM external group as an external member. The AD member is identified by its fully-qualified name, such as DOMAIN\group_name or DOMAIN\username. The AD identity is then mapped to the Active Directory SID for the user or group.

For example, for an AD group:

[root@ipaserver ~]# ipa group-add-member ad_users_external --external "AD\Domain Users"
 [member user]:
 [member group]:
  Group name: ad_users_external
  Description: AD users external map
  External member: S-1-5-21-3655990580-1375374850-1633065477-513 SID_DOM_GROUP (2)
-------------------------
Number of members added 1
-------------------------

Add the external IdM group to the POSIX IdM group as a member. For example:

[root@ipaserver ~]# ipa group-add-member ad_users --groups ad_users_external
  Group name: ad_users
  Description: AD users
  GID: 129600004
  Member groups: ad_users_external
-------------------------
Number of members added 1
-------------------------

5.3.4. Maintaining Trusts

Trust management involves several areas, such as global trust configuration, Kerberos trust configuration, DNS realm configuration, or ID ranges assignment to Active Directory users.

5.3.4.1. Editing the Global Trust Configuration

The ipa-adtrust-install utility automatically automatically configures background information for the IdM domain which is required to create a trust with the Active Directory domain.

The global trust configuration contains five attributes:

A Windows-style security ID (SID); this attribute is autogenerated and cannot be modified
A domain GUID; this attribute is autogenerated and cannot be modified
A Kerberos domain name; this attribute comes from the IdM configuration and cannot be modified
The default group to which to add IdM users; this attribute can be modified
The NetBIOS name; it is not recommended to modify this attribute

The trust configuration is stored in the cn=domain,cn=ad,cn=etc,dc=example,dc=com subtree.

5.3.4.1.1. Changing the NetBIOS Name

Important

Changing the NetBIOS name in most cases requires to re-establish all existing trusts. Therefore, Red Hat recommends not to change the attribute.

A NetBIOS name compatible within an Active Directory topology is configured for the IdM server when running the ipa-adtrust-install utility. To change it later, run ipa-adtrust-install again and specify the new NetBIOS name using the --netbios-name option:

[root@ipaserver ]# ipa-adtrust-install --netbios-name=NEWBIOSNAME

5.3.4.1.2. Changing the Default Group for Windows Users

When Identity Management is configured to trust an Active Directory forest, an MS-PAC record is added to the Kerberos tickets of IdM users. An MS-PAC record contains security identifiers (SIDs) of the groups to which an IdM user belongs. If the primary group of the IdM user has no SID assigned, the value of the security identifier defined for the Default SMB Group will be used. The same logic is applied by the Samba suite when the AD domain controller requests user information from the IdM trust controller.

The Default SMB Group is a fallback group created automatically by the ipa-adtrust-install utility. The default group cannot be deleted, but you can use the global trust configuration to specify another IdM group to be used as a fallback for the primary group of the IdM users.

To set the default group from the command line, use the ipa trustconfig-mod command:

[root@server ~]# kinit admin
[root@server ~]# ipa trustconfig-mod --fallback-primary-group="Example Windows Group"

To set the default group from the IdM web UI:

Open the IdM web UI.
```
https://ipaserver.example.com
```
Under the IPA Server main tab, select the Trusts subtab, and then open the Global Configuration section.
Select a new group from all of the IdM groups in the Fallback primary group drop-down list.
Figure 5.6. Configuring the Default Group for Windows Users
Click Save to save the new configuration.

5.3.4.2. Discovering, Enabling, and Disabling Trust Domains

A transitive trust means that the trust path can follow a chain of domains. It is described in more detail in Section 5.1.1, “The Architecture of a Trust Relationship”.

IdM has a trust with the root domain in a forest, and due to transitivity, all of its subdomains and trusted domains are implicitly included in that trust. IdM follows that topology as Windows users from anywhere in the forest attempt to access IdM resources. Each domain and subdomain is a trust domain in the IdM trust configuration. Each domain is stored in its own entry, cn=subdomain,cn=trust_name,cn=ad,cn=trusts,dc=example,dc=com in the trusts subtree.

IdM attempts to discover and map the full Active Directory topology when the trust is first configured, although in some cases it is required or beneficial to retrieve that topology manually. That is done with the trust-fetch-domains command:

[root@ipaserver ~]# kinit admin
[root@ipaserver ~]# ipa trust-fetch-domains ad.example.com
--------------------------------------------
List of trust domains successfully refreshed
--------------------------------------------
  Realm name: test.ad.example.com
  Domain NetBIOS name: TEST
  Domain Security Identifier: S-1-5-21-87535643-5658642561-5780864324

  Realm name: users.ad.example.com
  Domain NetBIOS name: USERS
  Domain Security Identifier: S-1-5-21-91314187-2404433721-1858927112

  Realm name: prod.ad.example.com
  Domain NetBIOS name: PROD
  Domain Security Identifier: S-1-5-21-46580863-3346886432-4578854233
----------------------------
Number of entries returned 3
----------------------------

Note

When adding a trust with a shared secret, you need to manually retrieve topology of the AD forest. After running the ipa trust-add ad.domain --trust-secret command, validate incoming trust at AD side using forest trust properties in the AD Domains and Trusts tool. Then, run the ipa trust-fetch-domains ad.domain command. IdM will receive information about the trust, which will then be usable.

Once the topology is retrieved (through automatic or manual discovery), individual domains and subdomains in that topology can be enabled, disabled, or removed entirely within the IdM trust configuration.

For example, to disallow users from a specific subdomain from using IdM resources, disable that trust domain:

[root@ipaserver ~]# kinit admin
[root@ipaserver ~]# ipa trustdomain-disable test.ad.example.com
------------------------------------------
Disabled trust domain "test.ad.example.com"
------------------------------------------

That trust domain can be re-enabled using the trustdomain-enable command.

If a domain should be permanently removed from the topology, than it can be deleted from the IdM trust configuration.

[root@ipaserver ~]# kinit admin
[root@ipaserver ~]# ipa trustdomain-del prod.ad.example.com
-------------------------------------------------------------------
Removed information about the trusted domain " "prod.ad.example.com"
-------------------------------------------------------------------

5.3.4.3. Viewing and Managing DNS Realms

When a trust is created, the Active Directory DNS configuration is added to the IdM DNS configuration, with each realm being added as a special realm domain. Each domain is stored in the cn=Realm Domains,cn=ipa,cn=etc,dc=example,dc=com subtree in the IdM directory.

Since these realm domains are added automatically, the DNS zones do not generally need to be added or modified. The list of configured realm domains can be displayed (instead of listing all DNS zones configured in IdM) using the realmdomains-show command.

[root@ipaserver ~]# kinit admin
[root@ipaserver ~]# ipa realmdomains-show
 Domain: ipa.example.org, ipa.example.com, example.com

If a single realm domain should be added to the configuration, this can be done with the --add-domain option.

[root@ipaserver ~]# kinit admin
[root@ipaserver ~]# ipa realmdomains-mod --add-domain=ad.example.com
 Domain: ipa.example.org, ipa.example.com, example.com, ad.example.com

A single domain can be removed using the --del-domain option.

If there are multiple changes to be made to the list of domains, the list itself can be modified and replaced using the --domain option.

[root@ipaserver ~]# ipa realmdomains-mod --domain={ipa.example.org,ad.example.com}

5.3.4.4. Adding Ranges for UID and GID Numbers in a Transitive Trust

Creating ID ranges at the time when a trust is originally configured is described in the section called “ID Ranges”. To add an ID range later, use the ipa idrange-add command with the following options:

the --base-id option sets the base ID for the POSIX range, which is the starting number
the --range-size option sets the size of the range
the --rid-base option sets the starting number of the RID, which is the far-right number in the SID; the value represents the range to add to the base ID to prevent conflicts
the --dom-sid option sets the domain SID, because there can be multiple domains configured for trusts

In the following example, the base ID is 1,200,000 and the RID is 1,000. The resulting ID number is then 1,201,000.

[root@server ~]$ kinit admin
[root@server ~]$ ipa idrange-add --base-id=1200000 --range-size=200000 --rid-base=0 --dom-sid=S-1-5-21-123-456-789 trusted_dom_range

Important

Make sure that the manually defined ID range does not overlap with the ID range used by IdM.

5.3.4.5. Kerberos Flags for Services and Hosts

Accessing services or hosts in a trusted domain can require special flags for the Kerberos ticket-granting ticket (TGT). For example, if you want to log in using single sign-on to an IdM client with an Active Directory (AD) account from an AD client, the Kerberos TGT flag OK_AS_DELEGATE is required.

For more information and how to set Kerberos flags, see Kerberos Flags for Services and Hosts in the Linux Domain Identity, Authentication, and Policy Guide.

5.3.5. Setting PAC Types for Services

On IdM resources, if an Active Directory user requests a ticket for a service, then IdM forwards the request to Active Directory to retrieve the user information. Access data, associated with the Active Directory group assignments for the user, is sent back by Active Directory and embedded in the Kerberos ticket.

Group information in Active Directory is stored in a list of identifiers in each Kerberos ticket for Active Directory users in a special data set called privileged access certificates or MS-PAC. The group information in the PAC has to be mapped to the Active Directory groups and then to the corresponding IdM groups to help determine access.

IdM services can be configured to generate PACs for each authentication request when a user first attempts to authenticate to a domain service.

5.3.5.1. Setting Default PAC Types

The IdM server configuration defines which PAC types are generated by default for a service. The global settings can be overridden by changing the local settings on a specific service.

Open the IPA Server tab.
Select the Configuration subtab.
Scroll to the Service Options area.
Figure 5.7. The Service Options Area
To use PAC, select the MS-PAC check box, which adds a certificate that can be used by AD services. If no check box is selected, then no PAC is added to Kerberos tickets.
If you select the nfs:NONE check box, the MS-PAC record will not be added to the service tickets issued against NFS servers.
Note
You can ignore the PAD check box. This functionality is not yet available in IdM.
Click the Update link at the top of the page to save the changes.

5.3.5.2. Setting PAC Types for a Service

The global policy sets what PAC types to use for a service if nothing is set explicitly for that service. However, the global settings can be overridden on the local service configuration.

To change the PAC setting from the command line, use the ipa service-mod command with the --pac-type option. For information on how to use the command, run it with the --help option added:

$ ipa service-mod --help
Usage: ipa [global-options] service-mod PRINCIPAL [options]

Modify an existing IPA service.
Options:
-h, --help            show this help message and exit
...

To change the PAC setting in the web UI:

Open the Identity tab, and select the Services subtab.
Click the name of the service to edit.
In the Service Settings area, check the Override inherited settings option and then select the MS-PAC check box to add a certificate that can be used by AD services.
Figure 5.8. The Service Settings Area
If no check box is selected, then no PACs are added to Kerberos tickets.
Note
You can ignore the PAD check box. This functionality is not yet available in IdM.
Click the Update link at the top of the page to save the changes.

5.3.6. Using POSIX Attributes Defined in Active Directory

5.3.6.1. Defining UID and GID Attributes for Active Directory Users

If the Windows administrator manually defines POSIX UID and GID attributes for a user, create a matching group on the IdM server with the same GID for the user.

Creating the group ensures that the user is associated with a primary user group. If such group does not exist, the IdM server is unable to look up all groups to which the user belongs.

5.3.6.2. Transferring Login Shell and Home Directory Attributes

Important

The client must be enrolled with an IdM server based on Red Hat Enterprise Linux 7.1 or later to benefit from this functionality.

SSSD is able to read the following attribute values from an Active Directory server in a trust relationship with IdM:

the loginShell attribute, which specifies the AD user's shell
the unixHomeDirectory attribute, which specifies the AD user's home directory

When a custom shell or home directory value is defined on the AD server using these attributes, the custom value is then displayed to the IdM client for the AD user. Therefore, the same user shell is displayed for the AD user both on the AD side and on the IdM side.

Note that to display the AD user's home directory to the IdM client, the subdomain_homedir option in the [domain] section of the /etc/sssd/sssd.conf file on the IdM server must be set to %o. The %o value represents the home directory retrieved from the identity provider. For example:

[domain/example.com]
subdomain_homedir = %o

If the AD administrator modifies loginShell or unixHomeDirectory on the AD side, the change is automatically reflected on the IdM side as well. If the attributes are not defined on the AD server, SSSD uses a template default value. This default value is then displayed to the IdM client.

5.3.7. Using SSH from Active Directory Machines for IdM Resources

When a trust is configured, Active Directory users can access machines, services, and files on IdM hosts using SSH and their AD credentials.

5.3.7.1. Using SSH Without Passwords

The localauth Kerberos plug-in for local authorization ensures that Kerberos principals are automatically mapped to local SSSD user names. With localauth, Windows users from a trusted AD domain are not prompted for a password when logging in using Kerberos and can therefore use SSH without passwords.

The plug-in provides a reliable mapping mechanism across multiple realms and trusts: when sssd connects to the Kerberos library to map the principal to a local POSIX identity, the SSSD plug-in maps them according to the trust agreements defined in IdM.

Kerberos Authentication for AD Users on Red Hat Enterprise Linux 7.1 and newer Systems

In Red Hat Enterprise Linux 7.1 and newer systems, SSSD automatically configures the localauth Kerberos plug-in.

SSSD allows user names in the format user@AD.DOMAIN, ad.domain\user and AD\user.

Note

On systems with localauth, it is not required to set the auth_to_local option in the /etc/krb5.conf file or list Kerberos principals in the .k5login file. The localauth plug-in makes this previously used configuration for logins without passwords obsolete.

Manual Configuration of Kerberos Authentication for AD Users

On systems where the localauth plug-in is not present, SSH prompts for a user password for Active Directory domain users even if the user obtains a proper Kerberos ticket.

To enable Active Directory users to use Kerberos for authentication in this situation, configure the auth_to_local option in the /etc/krb5.conf file or list the user Kerberos principals in the .k5login file in the home directory of the user.

Configuring /etc/krb5.conf

The following procedure describes how to configure realm mapping in the Kerberos configuration.

Open the /etc/krb5.conf file.
In the [realms] section, identify the IdM realm by name, and then add two auth_to_local lines to define the Kerberos principal name mapping:
- In one rule, include a rule to map different Active Directory user name formats and the specific Active Directory domain.
- In the other rule, set the value of DEFAULT, for standard Unix user names.
For example:
```
[realms]
IDM = {
....
auth_to_local = RULE:[1:$1@$0](^.*@ADDOMAIN$)s/@ADDOMAIN/@addomain/
auth_to_local = DEFAULT
}
```

Restart the KDC service.

[root@server ~]# systemctl restart krb5kdc.service

Note that if you configure Kerberos authentication using the auth_to_local option, the user name used for SSH access must meet the following criteria:

The user name must have the format ad_user@ad_domain.
The domain name must be lowercase.
The case of the user name must match the case of the user name in Active Directory. For example, user and User are considered different users because of the different cases.

For more information about setting auth_to_local, see the krb5.conf(5) man page.

Configuring .k5login

The following procedure configures the system to find the Kerberos principal name for a local user name.

Create the .k5login file in the user's home directory.
List the Kerberos principals used by the user in the file.

If the authenticating user matches the principal in an existing Kerberos ticket, the user is allowed to log in using the ticket and is not prompted for a password.

Note that if you configure Kerberos authentication using the .k5login configuration, the user name used for SSH access must have the format ad_user@ad_domain.

For more information about configuring the .k5login file, see the .k5login(5) man page.

Either one of these configuration procedures results in AD users being able to log in using Kerberos.

5.3.8. Using a Trust with Kerberos-enabled Web Applications

Any existing web application can be configured to use Kerberos authentication, which references the trusted Active Directory and IdM Kerberos realms. For the full Kerberos configuration directives, see the Configuration page for the mod_auth_kerb module.

Note

After changing the Apache application configuration, restart the Apache service:

[root@ipaserver ~]# systemctl restart httpd.service

For example, for an Apache server, there are several options that define how the Apache server connects to the IdM Kerberos realm:

KrbAuthRealms: The KrbAuthRealms option gives the application location to the name of the IdM domain. This is required.
Krb5Keytab: The Krb5Keytab option gives the location for the IdM server keytab. This is required.
KrbServiceName: The KrbServiceName option sets the Kerberos service name used for the keytab (HTTP). This is recommended.
KrbMethodK5Passwd and KrbMethodNegotiate: The KrbMethodK5Passwd Kerberos method option enables password-based authentication for valid users. The KrbMethodNegotiate option enables single sign-on (SSO) if a valid Kerberos ticket is available.
These options are recommended for ease of use for many users.
KrbLocalUserMapping: The KrbLocalUserMapping option enables normal web logins (which are usually the UID or common name of the account) to be mapped to the fully-qualified user name (which has a format of user@REALM.COM).
This option is strongly recommended. Without the domain name/login name mapping, the web login appears to be a different user account than the domain user. This means that users cannot see their expected data.
For information on supported user name formats, see Section 5.2.1.7, “Supported User Name Formats”.

Example 5.1. Kerberos Configuration in an Apache Web Application

<Location "/mywebapp">
   AuthType Kerberos
   AuthName "IPA Kerberos authentication"
   KrbMethodNegotiate on
   KrbMethodK5Passwd on
   KrbServiceName HTTP
   KrbAuthRealms IDM_DOMAIN
   Krb5Keytab /etc/httpd/conf/ipa.keytab
   KrbLocalUserMapping on
   KrbSaveCredentials off
   Require valid-user
</Location>

Where did the comment section go?

Red Hat's documentation publication system recently went through an upgrade to enable speedier, more mobile-friendly content. We decided to re-evaluate our commenting platform to ensure that it meets your expectations and serves as an optimal feedback mechanism. During this redesign, we invite your input on providing feedback on Red Hat documentation via the discussion platform.