Red Hat Enterprise Linux 8 Show
Documentation for planning Identity Management and setting up access controlAbstract This document describes the planning of Identity Management services on Red Hat Enterprise Linux 8. Making open source more inclusiveRed Hat is committed to replacing problematic language in our code, documentation, and web properties. We are beginning with these four terms: master, slave, blacklist, and whitelist. Because of the enormity of this endeavor, these changes will be implemented gradually over several upcoming releases. For more details, see our CTO Chris Wright’s message. In Identity Management, planned terminology replacements include:
Providing feedback on Red Hat documentationWe appreciate your feedback on our documentation. Let us know how we can improve it. Submitting comments on specific passages
Submitting feedback through Bugzilla (account required)
planning-identity-management :parent-context-of-overview-of-planning-idm-and-access-control: planning-identity-management planning-identity-management Chapter 1. Overview of planning for IdM and access control in RHELThe following sections provide an overview of the options for identity management (IdM) and access control in Red Hat Enterprise Linux. After reading these sections, you will be able to approach the planning stage for your environment. 1.1. Introduction to IdMThis module explains the purpose of Identity Management (IdM) in Red Hat Enterprise Linux. It also provides basic information about the IdM domain, including the client and server machines that are part of the domain. The goal of IdM in Red Hat Enterprise Linux IdM in Red Hat Enterprise Linux provides a centralized and unified way to manage identity stores, authentication, policies, and authorization policies in a Linux-based domain. IdM significantly reduces the administrative overhead of managing different services individually and using different tools on different machines. IdM is one of the few centralized identity, policy, and authorization software solutions that support:
IdM creates a Linux-based and Linux-controlled domain:
Managing identities and policies on multiple Linux servers Without IdM: Each server is administered separately. All passwords are saved on the local machines. The IT administrator manages users on every machine, sets authentication and authorization policies separately, and maintains local passwords. However, more often the users rely on other centralized solution, for example direct integration with AD. Systems can be directly integrated with AD using several different solutions:
With IdM: The IT administrator can:
Enterprise SSO In case of IdM Enterprise, single sign-on (SSO) is implemented leveraging the Kerberos protocol. This protocol is popular in the infrastructure level and enables SSO with services such as SSH, LDAP, NFS, CUPS, or DNS. Web services using different web stacks (Apache, EAP, Django, and others) can also be enabled to use Kerberos for SSO. However, practice shows that using OpenID Connect or SAML based on SSO is more convenient for web applications. To bridge the two layers, it is recommended to deploy an Identity Provider (IdP) solution that would be able to convert Kerberos authentication into a OpenID Connect ticket or SAML assertion. Red Hat SSO technology based on the Keycloak open source project is an example of such an IdP Without IdM: Users log in to the system and are prompted for a password every single time they access a service or application. These passwords might be different, and the users have to remember which credential to use for which application. With IdM: After users log in to the system, they can access multiple services and applications without being repeatedly asked for their credentials. This helps to:
Managing a mixed Linux and Windows environment Without IdM: Windows systems are managed in an AD forest, but development, production, and other teams have many Linux systems. The Linux systems are excluded from the AD environment. With IdM: The IT administrator can:
Contrasting IdM with a Standard LDAP Directory A standard LDAP directory, such as Red Hat Directory Server, is a general-purpose directory: it can be customized to fit a broad range of use cases.
IdM has a specific purpose: managing internal, inside-the-enterprise identities as well as authentication and authorization policies that relate to these identities.
The underlying directory server technology is the same for both Red Hat Directory Server and IdM. However, IdM is optimized to manage identities inside the enterprise. This limits its general extensibility, but also brings certain benefits: simpler configuration, better automation of resource management, and increased efficiency in managing enterprise identities. Additional resources
1.2. Common IdM customer scenarios and their solutionsBelow are examples of common identity management and access control use cases both in Linux and Windows environments, and their solutions. Scenario 1 SituationYou are a Windows administrator in your company. Apart from Windows systems, you also have several Linux systems to administer. As you cannot delegate control of any part of your environment to a Linux administrator, you must handle all security controls in Active Directory (AD). SolutionIntegrate your Linux hosts to AD directly. If you want Connect with the Linux community to see how others manage identities: users, hosts, and services. Research best practices. Make yourself more familiar with Linux:
Scenario 2 SituationYou are a Linux administrator in your company. Your Linux users require different levels of access to the company resources. You need tight, centralized access control of your Linux machines. Solution Install IdM and migrate your users to it. Further advice if you are expecting your company to scale up in the futureAfter installing IdM, configure host-based access control and sudo rules. These are necessary to maintain security best practices of limited access and least privilege. To meet your security targets, develop a cohesive identity and access management (IAM) strategy that uses protocols to secure both infrastructure and application layers. Scenario 3 SituationYou are a Linux administrator in your company and you must integrate your Linux systems with the company Windows servers. You want to remain the sole maintainer of access control to your Linux systems. Different users require different levels of access to the Linux systems but they all reside in AD. Solution As AD controls are not robust enough, you must configure access control to the Linux systems on the Linux side. Install IdM and establish an IdM-AD trust. Further advice to enhance the security of your environmentAfter installing IdM, configure host-based access control and sudo rules. These are necessary to maintain security best practices of limited access and least privilege. To meet your security targets, develop a cohesive identity and access management (IAM) strategy that uses protocols to secure both infrastructure and application layers. Scenario 4 Situation As a security administrator, you must manage identities and access across all of your environments, including all of your Red Hat products. You must manage all of your identities in one place, and maintain access controls across all of your platforms, clouds and products. Solution Integrate IdM, Red Hat Single Sign-On, Red Hat Satellite, Red Hat Ansible Tower and other Red Hat products.Scenario 5 Situation As a security and system administrator in a Department of Defense (DoD) or Intelligence Community (IC) environment, you are required to use smart card or RSA authentication. You are required to use PIV certificates or RSA tokens. Solution
1.3. Introduction to IdM servers and clientsThe Identity Management (IdM) domain includes the following types of systems: IdM servers IdM servers are Red Hat Enterprise Linux systems that respond to identity, authentication, and authorization requests within an IdM domain. In most deployments, an integrated certificate authority (CA) is also installed with the IdM server. IdM servers are the central repositories for identity and policy information. IdM servers can also host any of the optional services used by domain members:
IdM clients are Red Hat Enterprise Linux systems enrolled with the servers and configured to use the IdM services on these servers. Clients interact with the IdM servers to access services provided by them. For example, clients use the Kerberos protocol to perform authentication and acquire tickets for enterprise single sign-on (SSO), use LDAP to get identity and policy infromation, use DNS to detect where the servers and services are located and how to connect to them. IdM servers are also embedded IdM clients. As clients enrolled with themselves, the servers provide the same functionality as other clients. To provide services for large numbers of clients, as well as for redundancy and availability, IdM allows deployment on multiple IdM servers in a single domain. It is possible to deploy up to 60 servers. This is the maximum number of IdM servers, also called replicas, that is currently supported in the IdM domain. IdM servers provide different services for the client. Not all the servers need to provide all the possible services. Some server components like Kerberos and LDAP are always available on every server. Other services like CA, DNS, Trust Controller or Vault are optional. This means that different servers in general play different roles in the deployment. If your IdM topology contains an integrated CA, one server has the role of the Certificate revocation list (CRL) publisher server and one server has the role of the CA renewal server. By default, the first CA server installed fulfills these two roles, but you can assign these roles to separate servers. For redundancy and load balancing, administrators create additional servers by creating a replica of an existing server. When creating a replica, IdM clones the configuration of the existing server. A replica shares with the initial server its core configuration, including internal information about users, systems, certificates, and configured policies. A replica and the server it was created from are functionally identical, except for the CA renewal and CRL publisher roles. Therefore, the term server and replica are used interchangeably here depending on the context. 1.4. IdM and access control in RHEL: Central vs. localIn Red Hat Enterprise Linux, you can manage identities and access control policies using centralized tools for a whole domain of systems, or using local tools for a single system. Managing identities and policies on multiple Red Hat Enterprise Linux servers: With and without IdM With Identity Management IdM, the IT administrator can:
Without IdM:
1.5. IdM terminologyActive Directory forest An Active Directory (AD) forest is a set of one or more domain trees which share a common global catalog, directory schema, logical structure, and directory configuration. The forest represents the security boundary within which users, computers, groups, and other objects are accessible. For more information, see the Microsoft document on Forests. Active Directory global catalog The global catalog is a feature of Active Directory (AD) that allows a domain controller to provide information on any object in the forest, regardless of whether the object is a member of the domain controller’s domain. Domain controllers with the global catalog feature enabled are referred to as global catalog servers. The global catalog provides a searchable catalog of all objects in every domain in a multi-domain Active Directory Domain Services (AD DS). Active Directory security identifier A security identifier (SID) is a unique ID number assigned to an object in Active Directory, such as a user, group, or host. It is the functional equivalent of UIDs and GIDs in Linux. Ansible play Ansible plays are the building blocks of Ansible playbooks. The goal of a play is to map a group of hosts to some well-defined roles, represented by Ansible tasks. Ansible playbook An Ansible playbook is a file that contains one or more Ansible plays. For more information, see the official Ansible documentation about playbooks. Ansible task Ansible tasks are units of action in Ansible. An Ansible play can contain multiple tasks. The goal of each task is to execute a module, with very specific arguments. An Ansible task is a set of instructions to achieve a state defined, in its broad terms, by a specific Ansible role or module, and fine-tuned by the variables of that role or module. For more information, see the official Ansible tasks documentation. Apache web server The Apache HTTP Server, colloquially called
Apache, is a free and open-source cross-platform web server application, released under the terms of Apache License 2.0. Apache played a key role in the initial growth of the World Wide Web, and is currently the leading HTTP server. Its process name is An
entity that issues digital certificates. In Red Hat Identity Management, the primary CA is
In IdM, you can also create multiple sub-CAs. Sub-CAs are IdM CAs whose certificates are one of the following types:
See also Planning your CA services. Cross-forest trustA trust establishes an access relationship between two Kerberos realms, allowing users and services in one domain to access resources in another domain. With a cross-forest trust between an Active Directory (AD) forest root domain and an IdM domain, users from the AD forest domains can interact with Linux machines and services from the IdM domain. From the perspective of AD, Identity Management represents a separate AD forest with a single AD domain. For more information, see How the trust works. Directory Server A Directory Server centralizes user identity and application information. It provides an operating system-independent, network-based registry for storing application settings, user profiles, group data, policies, and access control information. Each resource on the network is considered an object by the directory server. Information about a particular resource is stored as a collection of attributes associated with that resource or object. Red Hat Directory Server conforms to LDAP standards. DNS PTR records DNS pointer (PTR) records resolve an IP address of a host to a domain or host name. PTR records are the opposite of DNS A and AAAA records, which resolve host names to IP addresses. DNS PTR records enable reverse DNS lookups. PTR records are stored on the DNS server. DNS SRV records A DNS service (SRV) record defines the hostname, port number, transport protocol, priority and weight of a service available in a domain. You can use SRV records to locate IdM servers and replicas.Domain Controller (DC) A domain controller (DC) is a host that responds to security authentication requests within a domain and controls access to resources in that domain. IdM servers work as DCs for the IdM domain. A DC authenticates users, stores user account information and enforces security policy for a domain. When a user logs into a domain, the DC authenticates and validates their credentials and either allows or denies access. Fully qualified domain name A fully qualified domain name (FQDN) is a domain name
that specifies the exact location of a host within the hierarchy of the Domain Name System (DNS). A device with the hostname If you are installing an IdM client on host The Generic Security Service Application Program Interface (GSSAPI, or GSS-API) allows developers to abstract how their applications protect data that is sent to peer applications. Security-service vendors can provide GSSAPI implementations of common procedure calls as libraries with their security software. These libraries present a GSSAPI-compatible interface to application writers who can write their application to use only the vendor-independent GSSAPI. With this flexibility, developers do not have to tailor their security implementations to any particular platform, security mechanism, type of protection, or transport protocol. Kerberos is the dominant GSSAPI mechanism implementation, which allows Red Hat Enterprise Linux and Microsoft Windows Active Directory Kerberos implementations to be API compatible. Hidden replicaA hidden replica is an IdM replica that has all services running and available, but its server roles are disabled, and clients cannot discover the replica because it has no SRV records in DNS. Hidden replicas are primarily designed for services such as backups, bulk importing and exporting, or actions that require shutting down IdM services. Since no clients use a hidden replica, administrators can temporarily shut down the services on this host without affecting any clients. For more information, see The hidden replica mode. HTTP server See Web server. ID mappingSSSD can use the SID of an AD user to algorithmically generate POSIX IDs in a process called ID mapping. ID mapping creates a map between SIDs in AD and IDs on Linux.
An ID range is a range of ID numbers assigned to the IdM topology or a specific replica. You can use ID ranges to specify the valid range of UIDs and GIDs for new users, hosts and groups. ID ranges are used to avoid ID number conflicts. There are two distinct types of ID ranges in IdM:
For more information, see ID ranges. ID viewsID views enable you to specify new values for POSIX user or group attributes, and to define on which client host or hosts the new values will apply. For example, you can use ID views to:
In an IdM-AD trust setup, the For more information, see Using an ID view to override a user attribute value on an IdM client. IdM CA serverAn IdM server on which the IdM certificate authority (CA) service is installed and running. Alternative names: CA server IdM deploymentA term that refers to the entirety of your IdM installation. You can describe your IdM deployment by answering the following questions:
To install the first server in an IdM deployment, you must use the Administrators can then use the There is no functional difference between the first server that was installed and a replica. Both are fully functional read/write IdM servers. Deprecated names: master server IdM CA renewal serverIf your IdM topology contains an integrated certificate authority (CA), one server has the unique role of the CA renewal server. This server maintains and renews IdM system certificates. By default, the first CA server you install fulfills this role, but you can configure any CA server to be the CA renewal server. In a deployment without integrated CA, there is no CA renewal server. Deprecated names: master CA IdM CRL publisher serverIf your IdM topology contains an integrated certificate authority (CA), one server has the unique role of the Certificate revocation list (CRL) publisher server. This server is responsible for maintaining the CRL. By default, the server that fulfills the CA renewal server role also fulfills this role, but you can configure any CA server to be the CRL publisher server. In a deployment without integrated CA, there is no CRL publisher server. IdM topology A term that refers to the structure of your IdM solution, especially the replication agreements between and within individual data centers and clusters. Kerberos authentication indicatorsAuthentication indicators are attached to Kerberos tickets and represent the initial authentication method used to acquire a ticket:
For more information, see Kerberos authentication indicators. Kerberos keytabWhile a password is the default authentication method for a user, keytabs are the default authentication method for hosts and services. A Kerberos keytab is a file that contains a list of Kerberos principals and their associated encryption keys, so a service can retrieve its own Kerberos key and verify a user’s identity. For example, every IdM client has an Unique Kerberos principals identify each user, service, and host in a Kerberos realm:
The Kerberos Key Distribution Center (KDC) enforces ticket access control through connection policies, and manages the duration of Kerberos tickets through ticket lifecycle policies. For example, the default global ticket lifetime is one day, and the default global maximum renewal age is one week. For more information, see IdM Kerberos ticket policy types. Key Distribution Center (KDC)The Kerberos Key Distribution Center (KDC) is a service that acts as the central, trusted authority that manages Kerberos credential information. The KDC issues Kerberos tickets and ensures the authenticity of data originating from entities within the IdM network. For more information, see The role of the IdM KDC. LDAP The Lightweight Directory Access Protocol (LDAP) is an open, vendor-neutral, application protocol for accessing and maintaining distributed directory information services over a network. Part of this specification is a directory information tree (DIT), which represents data in a hierarchical tree-like structure consisting of the Distinguished Names (DNs) of directory service entries. LDAP is a "lightweight" version of the Directory Access Protocol (DAP) described by the ISO X.500 standard for directory services in a network. Lightweight sub-CAIn IdM, a lightweight sub-CA is a certificate authority (CA) whose certificate is signed by an IdM root CA or one of the CAs that are subordinate to it. A lightweight sub-CA issues certificates only for a specific purpose, for example to secure a VPN or HTTP connection. For more information, see Restricting an application to trust only a subset of certificates. Password policyA password policy is a set of conditions that the passwords of a particular IdM user group must meet. The conditions can include the following parameters:
For more information, see What is a password policy. POSIX attributesPOSIX attributes are user attributes for maintaining compatibility between operating systems. In a Red Hat Identity Management environment, POSIX attributes for users include:
In a Red Hat Identity Management environment, POSIX attributes for groups include:
These attributes identify users and groups as separate entities. Replication agreementA replication agreement is an agreement between two IdM servers in the same IdM deployment. The replication agreement ensures that the data and configuration is continuously replicated between the two servers. IdM uses two types of replication agreements: domain replication agreements, which replicate identity information, and certificate replication agreements, which replicate certificate information. For more information, see:
After authenticating to a Kerberos Key Distribution Center (KDC), a user receives a ticket-granting ticket (TGT), which is a temporary set of credentials that can be used to request access tickets to other services, such as websites and email. Using a TGT to request further access provides the user with a Single Sign-On experience, as the user only needs to authenticate once in order to access multiple services. TGTs are renewable, and Kerberos ticket policies determine ticket renewal limits and access control. For more information, see Managing Kerberos ticket policies. Web server A web server is computer software and underlying hardware that accepts requests for web content, such as pages, images, or applications. A user agent, such as a web browser, requests a specific resource using HTTP, the network protocol used to distribute web content, or its secure variant HTTPS. The web server responds with the content of that resource or an error message. The web server can also accept and store resources sent from the user agent. Red Hat Identity Management (IdM) uses the Apache Web Server to display the IdM Web UI, and to coordinate communication between components, such as the Directory Server and the Certificate Authority (CA). See Apache web server. Additional Glossaries If you are unable to find an Identity Management term in this glossary, see the Directory Server and Certificate System glossaries:
1.6. Additional resources
Chapter 2. Failover, load-balancing, and high-availability in IdMIdentity Management (IdM) has built-in failover mechanisms for IdM clients, and load-balancing and high-availability features for IdM servers. 2.1. Client-side failover capability
2.2. Server-side load-balancing and service availabilityYou can achieve load-balancing and high-availability in IdM by installing multiple IdM replicas:
Red Hat recommends against combining IdM and other load-balancing or high-availability (HA) software. Many third-party high availability solutions assume active/passive scenarios and cause unnecessary service interruption to IdM availability. Other solutions use virtual IPs or a single hostname per clustered service. All these methods do not typically work well with the type of service availability provided by the IdM solution. They also integrate very poorly with Kerberos, decreasing the overall security and stability of the deployment. Chapter 3. Planning the replica topologyThe following sections provide advice on determining the appropriate replica topology for your use case. 3.1. Multiple replica servers as a solution for high performance and disaster recoveryContinuous functionality and high availability of Identity Management (IdM) services is vital for users who access resources. One of the built-in solutions for accomplishing continuous functionality and high availability of the IdM infrastructure through load balancing is the replication of the central directory by creating replica servers of the first server. IdM allows placing additional servers in geographically dispersed data centers to reflect your enterprise organizational structure. In this way, the path between IdM clients and the nearest accessible server is shortened. In addition, having multiple servers allows spreading the load and scaling for more clients. Maintaining multiple redundant IdM servers and letting them replicate with each other is also a common backup mechanism to mitigate or prevent server loss. For example, if one server fails, the other servers keep providing services to the domain. You can also recover the lost server by creating a new replica based on one of the remaining servers. 3.2. Introduction to IdM servers and clientsThe Identity Management (IdM) domain includes the following types of systems: IdM servers IdM servers are Red Hat Enterprise Linux systems that respond to identity, authentication, and authorization requests within an IdM domain. In most deployments, an integrated certificate authority (CA) is also installed with the IdM server. IdM servers are the central repositories for identity and policy information. IdM servers can also host any of the optional services used by domain members:
IdM clients are Red Hat Enterprise Linux systems enrolled with the servers and configured to use the IdM services on these servers. Clients interact with the IdM servers to access services provided by them. For example, clients use the Kerberos protocol to perform authentication and acquire tickets for enterprise single sign-on (SSO), use LDAP to get identity and policy infromation, use DNS to detect where the servers and services are located and how to connect to them. IdM servers are also embedded IdM clients. As clients enrolled with themselves, the servers provide the same functionality as other clients. To provide services for large numbers of clients, as well as for redundancy and availability, IdM allows deployment on multiple IdM servers in a single domain. It is possible to deploy up to 60 servers. This is the maximum number of IdM servers, also called replicas, that is currently supported in the IdM domain. IdM servers provide different services for the client. Not all the servers need to provide all the possible services. Some server components like Kerberos and LDAP are always available on every server. Other services like CA, DNS, Trust Controller or Vault are optional. This means that different servers in general play different roles in the deployment. If your IdM topology contains an integrated CA, one server has the role of the Certificate revocation list (CRL) publisher server and one server has the role of the CA renewal server. By default, the first CA server installed fulfills these two roles, but you can assign these roles to separate servers. For redundancy and load balancing, administrators create additional servers by creating a replica of an existing server. When creating a replica, IdM clones the configuration of the existing server. A replica shares with the initial server its core configuration, including internal information about users, systems, certificates, and configured policies. A replica and the server it was created from are functionally identical, except for the CA renewal and CRL publisher roles. Therefore, the term server and replica are used interchangeably here depending on the context.
3.3. Replication agreementsWhen an administrator creates a replica based on an existing server, Identity Management (IdM) creates a replication agreement between the initial server and the replica. The replication agreement ensures that the data and configuration is continuously replicated between the two servers. IdM uses multiple read/write replica replication. In this configuration, all replicas joined in a replication agreement receive and provide updates, and are therefore considered suppliers and consumers. Replication agreements are always bilateral. Figure 3.1. Server and replica agreements IdM uses two types of replication agreements: Domain replication agreements These agreements replicate the identity information. Certificate replication agreements These agreements replicate the certificate information. Both replication channels are independent. Two servers can have one or both types of replication agreements configured between them. For example, when server A and server B have only domain replication agreement configured, only identity information is replicated between them, not the certificate information. 3.4. Determining the appropriate number of replicasSet up at least two replicas in each data center (not a hard requirement) A data center can be, for example, a main office or a geographical location. Set up a sufficient number of servers to serve your clients One Identity Management (IdM) server can provide services to 2000 - 3000 clients. This assumes the clients query the servers multiple times a day, but not, for example, every minute. If you expect more frequent queries, plan for more servers. Set up a sufficient number of Certificate Authority (CA) replicas Only replicas with the CA role installed can replicate certificate data. If you use the IdM CA, ensure your environment has at least two CA replicas with certificate replication agreements between them. Set up a maximum of 60 replicas in a single IdM domain Red Hat supports environments with up to 60 replicas. 3.5. Connecting the replicas in a topologyConnect each replica to at least two other replicas Configuring additional replication agreements ensures that information is replicated not just between the initial replica and the first server you installed, but between other replicas as well. Connect a replica to a maximum of four other replicas (not a hard requirement) A large number of replication agreements per server does not add significant benefits. A receiving replica can only be updated by one other replica at a time and meanwhile, the other replication agreements are idle. More than four replication agreements per replica typically means a waste of resources. This recommendation applies to both certificate replication and domain replication agreements. There are two exceptions to the limit of four replication agreements per replica:
Configuring a high number of replication agreements can have a negative impact on overall performance: when multiple replication agreements in the topology are sending updates, certain replicas can experience a high contention on the changelog database file between incoming updates and the outgoing updates. If you decide to use more replication agreements per replica, ensure that you do not experience replication issues and latency. However, note that large distances and high numbers of intermediate nodes can also cause latency problems. Connect the replicas in a data center with each other This ensures domain replication within the data center. Connect each data center to at least two other data centers This ensures domain replication between data centers. Connect data centers using at least a pair of replication agreements If data centers A and B have a replication agreement from A1 to B1, having a replication agreement from A2 to B2 ensures that if one of the servers is down, the replication can continue between the two data centers.3.6. Replica topology examplesThe figures below show examples of Identity Management (IdM) topologies based on the guidelines for creating a reliable topology. Replica Topology Example 1 shows four data centers, each with four servers. The servers are connected with replication agreements. Figure 3.2. Replica Topology Example 1 Replica Topology Example 2 shows three data centers, each with a different number of servers. The servers are connected with replication agreements. Figure 3.3. Replica Topology Example 2 3.7. The hidden replica modeBy default, when you set up a replica, the installation program automatically creates service (SRV) resource records in DNS. These records enable clients to auto-discover the replica and its services. A hidden replica is an IdM server that has all services running and available. However, it has no SRV records in DNS, and LDAP server roles are not enabled. Therefore, clients cannot use service discovery to detect these hidden replicas. The hidden replica feature, introduced in RHEL 8.1 as a Technology Preview, is fully supported starting with RHEL 8.2. Hidden replicas are primarily designed for dedicated services that can otherwise disrupt clients. For example, a full backup of IdM requires to shut down all IdM services on the server. As no clients use a hidden replica, administrators can temporarily shut down the services on this host without affecting any clients.
Other use cases include high-load operations on the IdM API or the LDAP server, such as a mass import or extensive queries. To install a replica as hidden, pass the For further details about installing a replica, see Installing an Identity Management replica. You can also change the state of an existing replica. For details, see Demoting or promoting hidden replicas. Chapter 4. Planning your DNS services and host namesIdentity Management (IdM) provides different types of DNS configurations in the IdM server. The following sections describe them and provide advice on how to determine which is the best for your use case. 4.1. DNS services available in an IdM serverYou can install an Identity Management (IdM) server with or without integrated DNS. Table 4.1. Comparing IdM with integrated DNS and without integrated DNS
Even if an Identity Management server is used as a primary DNS server, other external DNS servers can still be used as secondary servers. For example, if your environment is already using another DNS server, such as a DNS server integrated with Active Directory (AD), you can delegate only the IdM primary domain to the DNS integrated with IdM. It is not necessary to migrate DNS zones to the IdM DNS. If you need to issue certificates for IdM clients with an IP address in the Subject Alternative Name (SAN) extension, you must use the IdM integrated DNS service. 4.2. Guidelines for planning the DNS domain name and Kerberos realm nameWhen installing the first Identity Management (IdM) server, the installation prompts for a primary DNS name of the IdM domain and Kerberos realm name. The guidelines in this section can help you set the names correctly. You will not be able to change the IdM primary domain name and Kerberos realm name after the server is already installed. Do not expect to be able to move from a testing environment to a production environment by changing the names, for example from A separate DNS domain for service records Ensure that the primary DNS
domain used for IdM is not shared with any other system. This helps avoid conflicts on the DNS level. Proper DNS domain name delegation Ensure you have valid delegation in the public DNS tree for the DNS domain. Do not use a domain name that is not delegated to you, not even on a private network. Multi-label DNS domain Do not use single-label domain names, for example Consider setting the realm name to an upper-case ( If you do not set the Kerberos realm name to be the upper-case version of the primary DNS name, you will not be able to use AD trusts. Additional notes on planning the DNS domain name and Kerberos realm name
Planning DNS forwarding
Chapter 5. Planning your CA servicesIdentity Management (IdM) in Red Hat Enterprise Linux provides different types of certificate authority (CA) configurations. The following sections describe different scenarios and provide advice to help you determine which configuration is best for your use case. CA subject DN The Certificate Authority (CA) subject distinguished name (DN) is the name of the CA. It must be globally unique in the Identity Management (IdM) CA infrastructure and cannot be changed after the installation. In case you need the IdM CA to be externally signed, you might need to consult the administrator of the external CA about the form your IdM CA Subject DN should take. 5.1. CA Services available in an IdM serverYou can install an Identity Management (IdM) server with an integrated IdM certificate authority (CA) or without a CA. Table 5.1. Comparing IdM with integrated CA and without a CA
Switching from the self-signed CA to an externally-signed CA, or the other way around, as well as changing which external CA issues the IdM CA certificate, is possible even after the installation. It is also possible to configure an integrated CA even after an installation without a CA. For more details, see Installing an IdM server: With integrated DNS, without a CA. 5.2. Guidelines for distribution of CA servicesThe following steps provide guidelines for the distribution of your certificate authority (CA) services. Procedure
See the following table for further recommendations on appropriate number of CA servers: Table 5.2. Guidelines for setting up appropriate number of CA servers
Chapter 6. Planning integration with ADThe following sections introduce the options for integrating Red Hat Enterprise Linux with Active Directory (AD). 6.1. Direct integrationIn direct integration, Linux systems are connected directly to Active Directory (AD). The following types of integration are possible: Integration with the System Security Services Daemon (SSSD) SSSD can connect a Linux system with various identity and authentication stores: AD, Identity Management (IdM), or a generic LDAP or Kerberos server. Notable requirements for integration with SSSD:
SSSD supports both direct and indirect integration. It also enables switching from one integration approach to the other without significant migration costs. Integration with Samba WinbindThe Winbind component of the Samba suite emulates a Windows client on a Linux system and communicates with AD servers. Notable requirements for integration with Samba Winbind:
Recommendations
6.2. Indirect integrationIn indirect integration, Linux systems are first connected to a central server which is then connected to Active Directory (AD). Indirect integration enables the administrator to manage Linux systems and policies centrally, while users from AD can transparently access Linux systems and services. Integration based on cross-forest trust with AD The Identity Management (IdM) server acts as the central server to control Linux systems. A cross-realm Kerberos trust with AD is established, enabling users from AD to log on to access Linux systems and resources. IdM presents itself to AD as a separate forest and takes advantage of the forest-level trusts supported by AD. When using a trust:
This approach is based on the WinSync tool. A WinSync replication agreement synchronizes user accounts from AD to IdM. WinSync is no longer actively developed in Red Hat Enterprise Linux 8. The preferred solution for indirect integration is cross-forest trust. The limitations of integration based on synchronization include:
6.3. Deciding between indirect and direct integrationThe guidelines in this section can help decide which type of integration fits your use case. Number of systems to be connected to Active DirectoryConnecting less than 30-50 systems (not a hard limit) If you connect less than 30-50 systems, consider direct integration. Indirect integration might introduce unnecessary overhead. Connecting more than 30-50 systems (not a hard limit) If you connect more than 30-50 systems, consider indirect integration with Identity Management. With this approach, you can benefit from the centralized management for Linux systems. Managing a small number of Linux systems, but expecting the number to grow rapidly In this scenario, consider indirect integration to avoid having to migrate the environment later. Frequency of deploying new systems and their typeDeploying bare metal systems on an irregular basis If you deploy new systems rarely and they are usually bare metal systems, consider direct integration. In such cases, direct integration is usually simplest and easiest. Deploying virtual systems frequently If you deploy new systems often and they are usually virtual systems provisioned on demand, consider indirect integration. With indirect integration, you can use a central server to manage the new systems dynamically and integrate with orchestration tools, such as Red Hat Satellite. Active Directory is the required authentication providerDo your internal policies state that all users must authenticate against Active Directory? You can choose either direct or indirect integration. If you use indirect integration with a trust between Identity Management and Active Directory, the users that access Linux systems authenticate against Active Directory. Policies that exist in Active Directory are executed and enforced during authentication. Chapter 7. Planning a cross-forest trust between IdM and ADActive Directory (AD) and Identity Management (IdM) are two alternative environments managing a variety of core services, such as Kerberos, LDAP, DNS, and certificate services. A cross-forest trust relationship transparently integrates these two diverse environments by enabling all core services to interact seamlessly. The following sections provide advice on how to plan and design a cross-forest trust deployment. 7.1. Cross-forest trusts between IdM and ADIn a pure Active Directory (AD) environment, a cross-forest trust connects two separate AD forest root domains. When you create a cross-forest trust between AD and IdM, the IdM domain presents itself to AD as a separate forest with a single domain. A trust relationship is then established between the AD forest root domain and the IdM domain. As a result, users from the AD forest can access the resources in the IdM domain. IdM can establish a trust with one AD forest or multiple unrelated forests. Two separate Kerberos realms can be connected in a cross-realm trust. However, a Kerberos realm only concerns authentication, not other services and protocols involved in identity and authorization operations. Therefore, establishing a Kerberos cross-realm trust is not enough to enable users from one realm to access resources in another realm. An external trust to an AD domainAn external trust is a trust relationship between IdM and an Active Directory domain. While a forest trust always requires establishing a trust between IdM and the root domain of an Active Directory forest, an external trust can be established from IdM to any domain within a forest. 7.2. Trust controllers and trust agentsIdentity Management (IdM) provides the following types of IdM servers that support trust to Active Directory (AD): Trust controllers IdM servers that can perform identity lookups against AD domain controllers. They also run the Samba suite so they can establish trust with AD. AD domain controllers contact trust controllers when establishing and verifying the trust to AD. AD-enrolled machines communicate with IdM trust controllers for Kerberos authentication requests. The first trust controller is created when you configure the trust. If you have multiple domain controllers across different geographic locations, use the Trust controllers run more network-facing services than trust agents, and thus present a greater attack surface for potential intruders. Trust agents IdM servers that can resolve identity lookups from RHEL IdM clients against AD domain controllers. Unlike trust controllers, trust agents cannot process Kerberos authentication requests.In addition to trust agents and controllers, the IdM domain can also include standard IdM servers. However, these servers do not communicate with AD. Therefore, clients that communicate with these standard servers cannot resolve AD users and groups or authenticate and authorize AD users. An IdM server is not configured to operate a Trust Controller or Trust Agent role unless either of the following actions were done:
Table 7.1. Comparing the capabilities supported by trust controllers and trust agents
When planning the deployment of trust controllers and trust agents, consider these guidelines:
If you ever want to create additional trust controllers or if an existing trust controller fails, create a new trust controller by promoting a trust agent or a standard server. To
do this, use the You cannot downgrade an existing trust controller to a trust agent. 7.3. One-way trusts and two-way trustsIn one way trusts, Identity Management (IdM) trusts Active Directory (AD) but AD does not trust IdM. AD users can access resources in the IdM domain but users from IdM cannot access resources within the AD domain. The IdM server connects to AD using a special account, and reads identity information that is then delivered to IdM clients over LDAP. In two way trusts, IdM users can authenticate to AD, and AD users can authenticate to IdM. AD users can authenticate to and access resources in the IdM domain as in the one way trust case. IdM users can authenticate but cannot access most of the resources in AD. They can only access those Kerberized services in AD forests that do not require any access control check. To be able to grant access to the AD resources, IdM needs to implement the Global Catalog service. This service does not yet exist in the current version of the IdM server. Because of that, a two-way trust between IdM and AD is nearly functionally equivalent to a one-way trust between IdM and AD. 7.4. Kerberos FAST for trusted domainsKerberos Flexible Authentication Secure Tunneling (FAST) is also called Kerberos armoring in an Active Directory (AD) environment. Kerberos FAST provides an additional security layer for the Kerberos communication between the clients and the Key Distribution Center (KDC). In IdM, the KDCs are running on the IdM servers and FAST is enabled by default. The Two-Factor Authentication (2FA) in IdM also requires enabling FAST. In AD, Kerberos
armoring is disabled by default on the AD Domain Controllers (DC). You can enable it on the Domain Controller on the
Once you enable KDC support for claims, the policy setting allows the following options:
Kerberos FAST is implemented in the Kerberos client libraries on IdM clients. You can configure IdM clients either to use FAST for all trusted domains which advertise FAST or to not use Kerberos FAST at all. If you enable Kerberos armoring in the trusted AD forest the IdM client uses Kerberos FAST by default. FAST establishes a secure tunneling with the help of a cryptographic key. To protect the connection to the domain controllers of a trusted domain, Kerberos FAST must get a cross-realm Ticket Granting Ticket (TGT) from the trusted domain because those keys are valid only inside the Kerberos realm. Kerberos FAST uses the Kerberos hosts keys of the IdM client to request the cross-realm TGT with the help of the IdM servers. That only works when the AD forest trusts the IdM domain which means a two-way trust is required. If AD policies require the enforcing of Kerberos FAST use, you need to establish a two-way trust between IdM domain and AD forest. You must plan this before the connection is established because both IdM and AD must have records about direction and the type of trust. If you already established a one-way trust, run the If using a two-way trust is not possible, you must disable Kerberos FAST on all IdM clients. The users from the trusted AD forest can authenticate with a password or
direct smart card. To disable Kerberos FAST, add the following setting to the krb5_use_fast = never Note, you do not need to use this option when the authentication is based on ssh-keys, GSSAPI authentication or SSH with smart cards from remote Windows clients. These methods do not use Kerberos FAST because the IdM client does not have to communicate with a DC. Additionally, after disabling FAST on the IdM client, the two-factor authentication IdM feature is also unavailable. 7.5. POSIX and ID mapping ID range types for AD users Identity Management (IdM) enforces access control rules based on the POSIX User ID (UID) and Group ID (GID) of a user. Active Directory (AD) users, however, are identified by Security Identifiers (SIDs). AD administrators can configure AD to store POSIX
attributes for your AD users and groups, such as You can configure a cross-forest trust to reference this information by establishing a trust with the [server ~]# ipa trust-add --type=ad ad.example.com --admin administrator --password --range-type=ipa-ad-trust-posix If you do not store POSIX attributes in AD, the System Security Services Daemon (SSSD) can consistently map a unique UID based on a user’s SID in a process called ID mapping. You can explicitly choose this behavior by creating a trust
with the [server ~]# ipa trust-add --type=ad ad.example.com --admin administrator --password --range-type=ipa-ad-trust If you do not specify an ID Range type when creating a trust, IdM attempts to automatically select the appropriate range type by requesting details from AD domain controllers in the forest root domain. If IdM does not detect any POSIX attributes, the trust installation script selects the If IdM detects any POSIX attributes in the forest root domain, the trust installation script selects the For example, if the users and groups that need access to IdM systems are not part of the forest root domain, but instead are located in a child domain of the forest domain, the installation script may not detect the POSIX attributes defined in the child AD domain. In this case, Red Hat recommends that you explicitly choose the POSIX ID range type when establishing the trust. 7.6. Options for automatically mapping private groups for AD users: POSIX trustsEach user in a Linux environment has a primary user group. Red Hat Enterprise Linux (RHEL) uses a user private group (UPG) scheme: a UPG has the same name as the user for which it was created and that user is the only member of the UPG. If you have allocated UIDs for your AD users, but GIDs were not added, you can configure SSSD to automatically map private groups for users based on their UID by adjusting the auto_private_groups setting for that ID range. By default, the auto_private_groups option is set to false for auto_private_groups = false SSSD assigns the Table 7.2. SSSD behavior when the
If an AD user does not have a primary group configured in AD, or its
SSSD always
maps a private group with the auto_private_groups = hybrid If the Table 7.4. SSSD
behavior when the
Additional resources
7.7. Options for automatically mapping private groups for AD users: ID mapping trustsEach user in a Linux environment has a primary user group. Red Hat Enterprise Linux (RHEL) uses a user private group (UPG) scheme: a UPG has the same name as the user for which it was created and that user is the only member of the UPG. If you have allocated UIDs for your AD users, but GIDs were not added, you can configure SSSD to automatically map private groups for users based on their UID by adjusting the auto_private_groups setting for that ID range. By default, the
SSSD always maps a private group with the GID set to match the UID, which is based on the SID of the AD user. auto_private_groups = false If you set the 7.8. Enabling automatic private group mapping for a POSIX ID range on the CLIBy default, SSSD does not map private groups for Active Directory (AD) users if you have established a POSIX trust that relies on POSIX data stored in AD. If any AD users do not have primary groups configured, IdM is not be able to resolve them. This procedure explains how to enable automatic private group mapping for an ID range by setting the Prerequisites
Procedure
7.9. Enabling automatic private group mapping for a POSIX ID range in the IdM WebUIBy default, SSSD does not map private groups for Active Directory (AD) users if you have established a POSIX trust that relies on POSIX data stored in AD. If any AD users do not have primary groups configured, IdM is not be able to resolve them. This procedure explains how to enable automatic private group mapping for an ID range by setting the Prerequisites
Procedure
7.10. Non-POSIX External Groups and SID MappingIdentity Management (IdM) uses LDAP for managing groups. Active Directory (AD) entries are not synchronized or copied over to IdM, which means that AD users and groups have no LDAP objects in the LDAP server, so they cannot be directly used to express group membership in the IdM LDAP. For this reason, administrators in IdM need to create non-POSIX external groups, referenced as normal IdM LDAP objects to signify group membership for AD users and groups in IdM. Security IDs (SIDs) for non-POSIX external groups are processed by SSSD, which maps the SIDs of groups in Active Directory to POSIX groups in IdM. In Active Directory, SIDs are associated with user names. When an AD user name is used to access IdM resources, SSSD uses the user’s SID to build up a full group membership information for the user in the IdM domain. 7.11. Setting up DNSThese guidelines can help you achieve the right DNS configuration for establishing a cross-forest trust between Identity Management (IdM) and Active Directory (AD). Unique primary DNS domains Ensure both AD and IdM have their own unique primary DNS domains configured. For example:
The most convenient management solution is an environment where each DNS domain is managed by integrated DNS servers, but you can also use any other standard-compliant DNS server. IdM and AD DNS Domains Systems joined to IdM can be distributed over multiple DNS domains. Red Hat recommends that you deploy IdM clients in a DNS zone different to the ones owned by Active Directory. The primary IdM DNS domain must have proper SRV records to support AD trusts.In some environments with trusts between IdM and Active Directory, you can install an IdM client on a host that is part of the Active Directory DNS domain. The host can then benefit from the Linux-focused features of IdM. This is not a recommended configuration and has some limitations. See Configuring IdM clients in an Active Directory DNS domain for more details. Proper SRV records Ensure the primary IdM DNS domain has proper SRV records to support AD trusts. For other DNS domains that are part of the same IdM realm, the SRV records do not have to be configured when the trust to AD is established. The reason is that AD domain controllers do not use SRV records to discover Kerberos key distribution centers (KDCs) but rather base the KDC discovery on name suffix routing information for the trust. DNS records resolvable from all DNS domains in the trustEnsure all machines can resolve DNS records from all DNS domains involved in the trust relationship:
ad.example.com for AD and idm.example.com for IdM, the Kerberos realm names must be AD.EXAMPLE.COM and IDM.EXAMPLE.COM . 7.12. NetBIOS namesThe NetBIOS name is usually the far-left component of the domain name. For example:
7.13. Supported versions of Windows ServerYou can establish a trust relationship with Active Directory (AD) forests that use the following forest and domain functional levels:
Identity Management (IdM) supports establishing a trust with Active Directory domain controllers running the following operating systems:
In RHEL 8.4, Identity Management (IdM) does not support establishing trust to Active Directory with Active Directory domain controllers running Windows Server 2008 R2 or earlier versions. RHEL IdM now requires SMB encryption when establishing the trust relationship, which is only supported in Windows Server 2012 or later. 7.14. Configuring AD server discovery and affinityServer discovery and affinity configuration affects which Active Directory (AD) servers an Identity Management (IdM) client communicates with. This section provides an overview of how discovery and affinity work in an environment with a cross-forest trust between IdM and AD. Configuring clients to prefer servers in the same geographical location helps prevent time lags and other problems that occur when clients contact servers from another, remote data center. To make sure clients communicate with local servers, you must ensure that:
Options for configuring LDAP and Kerberos on the IdM client for communication with local IdM serversWhen using IdM with integrated DNS By default, clients use automatic service lookup based on the DNS records. In this setup, you can also use the DNS locations feature to configure DNS-based service discovery. To override the automatic lookup, you can disable the DNS discovery in one of the following ways:
You must explicitly configure clients in one of the following ways:
Options for configuring Kerberos on the IdM client for communication with local AD servers IdM clients are unable to automatically discover
which AD servers to communicate with. To specify the AD servers manually, modify the
For example: [realms] AD.EXAMPLE.COM = { kdc = server1.ad.example.com kdc = server2.ad.example.com } Options for configuring embedded clients on IdM servers for communication with local AD servers over Kerberos and LDAPThe embedded client on an IdM server works also as a client of the AD server. It can automatically discover and use the appropriate AD site. When the embedded client performs the discovery, it might first discover an AD server in a remote location. If the attempt to contact the remote server takes too long, the client might stop the operation without establishing the connection. Use the Once the embedded client has been configured to communicate with the local AD servers, the SSSD remembers the AD site the embedded client belongs to. Thanks to this, SSSD normally sends an LDAP ping directly to a local domain controller to refresh its site information. If the site no longer exists or the client has meanwhile been assigned to a different site, SSSD starts querying for SRV records in the forest and goes through a whole process of autodiscovery. Using trusted domain sections in 7.15. Operations performed during indirect integration of IdM to AD
This section provides details on which operations and requests are performed during indirect integration of IdM to AD. Read the table to learn about operations and requests performed during the creation of an Identity Management (IdM) to Active Directory (AD) trust from the IdM trust controller towards AD domain controllers. Table 7.7. Operations performed from an IdM trust controller towards AD domain controllers
Read the table to learn about operations and requests performed during the creation of an IdM to AD trust from the AD domain controller towards IdM trust controllers. Chapter 8. Backing Up and Restoring IdMRed Hat Enterprise Linux Identity Management provides a solution to manually back up and restore the IdM system. This may be necessary after a data loss event. During backup, the system creates a directory containing information on your IdM setup and stores it. During restore, you can use this backup directory to bring your original IdM setup back. The IdM backup and restore features are designed to help prevent data loss. To mitigate the impact of losing a server, and ensure continued operation by providing alternative servers to clients, ensure you have a replica topology according to Mitigating server loss with replication. 8.1. IdM backup types With the Full-server backup
8.2. Naming conventions for IdM backup files By default, IdM
stores backups as The archives and subdirectories follow these naming conventions: Full-server backup An archive named [root@server ~]# ll /var/lib/ipa/backup/ipa-full-2021-01-29-12-11-46 total 3056 -rw-r--r--. 1 root root 158 Jan 29 12:11 header -rw-r--r--. 1 root root 3121511 Jan 29 12:11 ipa-full.tarData-only backup An archive named [root@server ~]# ll /var/lib/ipa/backup/ipa-data-2021-01-29-12-14-23 total 1072 -rw-r--r--. 1 root root 158 Jan 29 12:14 header -rw-r--r--. 1 root root 1090388 Jan 29 12:14 ipa-data.tar Uninstalling an IdM server does not automatically remove any backup files. 8.3. Considerations when creating a backup This section describes important behaviors and limitations of the
8.4. Creating an IdM backup This section describes how to create a full-server and data-only backup in offline and online modes using the Prerequisites
Procedure
If the backup fails due to insufficient space in the [root@server ~]# TMPDIR=/new/location ipa-backup For more details, see ipa-backup Command Fails to Finish. Verification Steps
8.5. Creating a GPG2-encrypted IdM backupYou can create encrypted backups using GNU Privacy Guard (GPG) encryption. The following procedure creates an IdM backup and encrypts it using a GPG2 key. Procedure
Verification Steps
8.6. Creating a GPG2 keyThe following procedure describes how to generate a GPG2 key to use with encryption utilities. Prerequisites
Procedure
Verification Steps
8.7. When to restore from an IdM backup
You can respond to several disaster scenarios by restoring from an IdM backup:
8.8. Considerations when restoring from an IdM backup If you have a backup created with the The following are the key considerations while restoring from an IdM backup:
Restoring from a backup requires the same software (RPM) versions on the target host as were installed when the backup was performed. Due to this, Red Hat recommends restoring from a Virtual Machine snapshot rather than a backup. For more information, see Recovering from data loss with VM snapshots. 8.9. Restoring an IdM server from a backupThe following procedure describes restoring an IdM server, or its LDAP data, from an IdM backup. Figure 8.1. Replication Topology used in this example Table 8.1. Server naming conventions used in this example
Prerequisites
Procedure
Additional resources
8.10. Restoring from an encrypted backup This procedure restores an IdM server from an encrypted IdM backup. The Prerequisites
Procedure
Chapter 9. Backing up and restoring IdM servers using Ansible playbooks Using the 9.1. Using Ansible to create a backup of an IdM serverThe following procedure describes how to use the ipabackup role in an Ansible playbook to create a backup of an IdM server and store it on the IdM server. Prerequisites
Procedure
Verification steps
Additional resources
9.2. Using Ansible to create a backup of an IdM server on your Ansible controller The following procedure describes how to use the Prerequisites
Procedure
Verification steps
Additional resources
9.3. Using Ansible to copy a backup of an IdM server to your Ansible controllerThe following procedure describes how to use an Ansible playbook to copy a backup of an IdM server from the IdM server to your Ansible controller. Prerequisites
Procedure
To copy all IdM backups to your controller, set the vars:
ipabackup_name: all
ipabackup_to_controller: yes For an example, see the Verification steps
Additional resources
9.4. Using Ansible to copy a backup of an IdM server from your Ansible controller to the IdM serverThe following procedure describes how to use an Ansible playbook to copy a backup of an IdM server from your Ansible controller to the IdM server. Prerequisites
Procedure
Additional resources
9.5. Using Ansible to remove a backup from an IdM serverThe following procedure describes how to use an Ansible playbook to remove a backup from an IdM server. Prerequisites
Procedure
To remove all IdM backups from the IdM server, set the vars:
ipabackup_name: all For an example, see the Additional resources
9.6. Using Ansible to restore an IdM server from a backup stored on the serverThe following procedure describes how to use an Ansible playbook to restore an IdM server from a backup stored on that host. Prerequisites
Procedure
Additional resources
9.7. Using Ansible to restore an IdM server from a backup stored on your Ansible controllerThe following procedure describes how to use an Ansible playbook to restore an IdM server from a backup stored on your Ansible controller. Prerequisites
Procedure
Additional resources
Chapter 10. IdM integration with other Red Hat productsThis section provides links to documentation for other Red Hat products that integrate with IdM. You can configure these products to allow your IdM users to access their services. Chapter 11. Configuring Single Sign-On for the RHEL 8 web console in the IdM domainLearn how to use Single Sign-on (SSO) authentication provided by Identity Management (IdM) in the RHEL 8 web console. Advantages:
This chapter covers the following steps to configure SSO for logging into the RHEL web console:
Prerequisites
11.1. Joining a RHEL 8 system to an IdM domain using the web consoleYou can use the web console to join the Red Hat Enterprise Linux 8 system to the Identity Management (IdM) domain. Prerequisites
Procedure
Verification steps
11.2. Logging in to the web console using Kerberos authenticationThe following procedure describes steps on how to set up the RHEL 8 system to use Kerberos authentication. With SSO you usually do not have any administrative privileges in the web console. This only works if you configured passwordless sudo. The web console does not interactively ask for a sudo password. Prerequisites
Procedure Log in to the RHEL web console with the following address: At this point, you are successfully connected to the RHEL web console and you can start with configuration.
11.3. Enabling admin sudo access to domain administrators on the IdM serverThe following procedure describes steps on how to allow domain administrators to run any command on any host in the Identity Management (IdM) domain. To accomplish this, enable sudo access to the admins user group created automatically during the IdM server installation. All users added to the admins group will have sudo access if you run Prerequisites
Procedure
If the console did not display an error, the admins group have admin permissions on all machines in the IdM domain. Legal NoticeCopyright © 2022 Red Hat, Inc. The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version. Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law. Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries. Linux® is the registered trademark of Linus Torvalds in the United States and other countries. Java® is a registered trademark of Oracle and/or its affiliates. XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries. MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries. Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project. The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community. All other trademarks are the property of their respective owners. How many types of replication are there in Active Directory?In active directory environment, there are mainly two types of replications. As the name confirms, this covers the replication happens with in a site. By default, (according to Microsoft) any domain controller will aware of any directory update within 15 seconds.
What is replication in Active Directory?Active Directory replication is the method of transferring and updating Active Directory objects from one DC to another DC. The connections between DCs are built based on their locations within a forest and site.
What is inbound and outbound replication in Active Directory?Inbound replication is the incoming data transfer from a replication partner to a DC, and outbound replication is the data transfer from a DC to its replication partner.
What type of Active Directory replication takes place between domain controllers in the same site?Intrasite replication takes place between servers in a site using RPCs, while intersite replication is mail based and takes place over a Directory Replication Connector (DRC) between bridgehead servers in separate sites.
|