Red Hat Security: Identity Management and Authentication

An IdM server or IdM instance is a system where the IdM service is installed. The IdM server provides a centralized way to maintain identities, apply policies, and manage access levels and privilege escalation for users.

An IdM replica is a server with the cloned configuration of an IdM server. When you create a replica, IdM creates the service SRV record in the DNS for clients to discover the replica and send requests. A replica can support the same functionality as the IdM server from which it was cloned. Because the original IdM server and the IdM replicas have the same functionality, the terms IdM server and IdM replica are commonly used interchangeably.

Red Hat recommends that you create replicas to scale your IdM service to serve many clients. To match your organization's infrastructure, you can deploy IdM servers in geographically distributed locations. Red Hat recommends deploying at least one IdM server and two IdM replicas in each data center or geographical location. Red Hat supports up to 60 replicas in a single IdM topology.

You can also use replicas as a backup strategy and defend against loss of information. In some scenarios, such as a maintenance window to back up server configurations, you might have to stop all services running on an IdM server. To avoid service interruption, you can stop the services of a hidden replica instead. A hidden replica is an IdM replica but is configured to not be discoverable for client data queries.

To access IdM services, a system must first join an IdM domain. An IdM client is an IdM domain member that consumes the services provided by IdM servers and is configured to use the domain's data.

IdM clients are typically RHEL systems, but you can configure other Linux and UNIX clients if they support the correct protocols and services. Although Microsoft Windows systems cannot be members of an IdM domain, you can configure a trust relationship with an Active Directory server to enable specific user and client capabilities between the RHEL and Windows systems.

An IdM client can interact with IdM services to perform the following tasks:

All IdM servers and replicas are also IdM clients to an existing IdM domain, and obtain client functionality from other IdM servers.

Depending on the required features for the IdM topology, an IdM server can host the following services:

IdM clients can host the following services:

An IdM server can have a combination of services installed. Depending on the installed services, the server can perform various server roles. For example, an IdM server might have one or all the following roles:

Most server roles can be added at any time. However, you need to assign the CA server or the DNS server role during installation if those services are planned. For the CA and DNS server roles, IdM adds all the required DNS service entries and installs the topology with the desired server roles.

You must be aware of the IdM server role assignments to verify that a particular service is available. If you plan to deploy an integrated certificate authority (CA), then you can assign the role to many servers. However, only one server can have the Certificate Revocation List (CRL) publisher server role and the CA renewal server role enabled at a time. If the server with the enabled CA renewal role fails or is decommissioned, then another server with the assigned role can provide the service.

By default, the first CA server installed provides these two roles, but you can enable the two roles on other replicas at any time.

IdM uses two types of replication agreements: domain replication agreements, and certificate replication agreements. Domain replication agreements replicate identity, system, and policy information.

Certificate replication agreements replicate certificate information, but only with IdM servers that have the CA role enabled. Red Hat recommends that you deploy at least two CA replicas with certificate replication agreements between them.

Figure 1.2: Types of replication agreements

Be mindful of the existing replication agreements between IdM servers to fully take advantage of the feature. Some replicas might have dependencies that can put the IdM topology at risk if a server fails. You can configure additional replication agreements to ensure that other replicas receive the configuration updates.

An IdM replica receives configuration updates by using only one replication agreement, regardless of the number of replication agreements configured. The unused replication agreements are considered idle and one of them can receive updates when the initial replication agreement is unavailable. Red Hat recommends that you connect an IdM server to a maximum of four replicas to avoid a possible waste of resources.

When an IdM server replicates data to a replica, the data is stored in a topology suffix. A topology suffix is a type of data to be synchronized between replicas. There are two topology suffixes supported by IdM:

Two replicas might synchronize one or both suffixes, depending on the configured services in the replica.

Figure 1.3: Topology suffix example

When two replicas have a replication agreement between their suffixes, the suffixes form a topology segment. If both domain and CA suffixes are synchronized, then there are two topology segments between the two replicas. Segments always synchronize data in both directions. In a topology segment, one server is referred to as the left node, and the other as the right node.

Figure 1.4: Topology segment example

Consider the following scenario, designed to deploy an IdM topology to serve a heavy load environment. You deploy the idm0 machine and create the idm1, idm2, and idm3 machines to replicate data from the idm0 machine.

In this topology, the initial IdM server and three replicas are all discoverable by IdM clients. All three replicas receive updates from the idm0 machine. If the idm0 machine fails, then all three replicas are disconnected from each other and cannot send or receive updates. Red Hat does not recommend this simplistic topology.

In this scenario, you might want to configure replication agreements between all IdM servers. This topology, where all servers replicate to each order, is called a tight cell topology. With the recommended four servers in a physical location, the tight cell topology configures three replication agreements per server. This configuration enables you to add replication agreements to servers in other geographical locations, and still comply with the recommended four maximum replication agreements for one server.

Figure 1.5: Example of a non-recommended topology and tight cell topology

In another scenario, where you might have geographically distributed clients, you can deploy the IdM servers in different data centers. The load of each region might not be heavy and you must ensure that the service responds from the nearest server to avoid delays or timeouts. Red Hat recommends that you configure replication agreements for an IdM server to a minimum of two replicas. Red Hat also recommends that you connect the data center to at least two other data centers.

The following diagram shows an IdM topology that complies with the requirements and recommendations of this scenario.

Figure 1.6: Example of a geographically distributed topology

By integrating Active directory with IdM you can benefit from the following features:

You can integrate Linux clients into an Active Directory domain by using direct integration or indirect integration.

When you configure direct integration, clients connect directly to an Active Directory domain. This method uses native LDAP, Kerberos, PAM, and NSS modules. With indirect integration, clients connect to an IdM domain that handles requests to Active Directory on their behalf. This method uses cross-realm Kerberos trust with Active Directory, or object synchronization between an IdM domain and Active Directory.

Linux and Windows systems use different attributes and structure to manage identities. For example, Linux uses POSIX-compliant user identifiers UID and group identifiers GID, whereas Microsoft Windows systems use security identifiers SID. However, Linux clients can use SSSD to authenticate with Active Directory. Active Directory assigns Active Directory users a UID and a GID to enable compatibility.

Active Directory can create and store POSIX attributes, such as uidNumber, gidNumber, unixHomeDirectory, and loginShell. An IdM server can query Active Directory POSIX attributes and cache the information locally. IdM servers can also create Active Directory POSIX attributes and account objects, eliminating the need for centralized POSIX data management.

Many organizations have a Kerberos realm deployed in their environments for application authentication and user management. You can use Kerberos as a common integration path for environments with Linux and Windows systems. To establish communication between the different Kerberos realms, you have to configure cross-realm trusts.

A Kerberos trust allows users in one realm to access the resources of another realm as if they belonged to that realm. Trusts can be one-way or two-way, although a two-way trust does not allow defined permissions for IdM users in Active Directory domains. You can create a trust by creating a shared key for a single principal that is held in common by both domains. IdM supports the configuration of a cross-forest trust between an IdM domain and an Active Directory domain. The cross-forest trusts and Active Directory integration topics are discussed in a later chapter.

The IdM domain synchronizes user data with the Active Directory domain. When this synchronization occurs, IdM uses the directory synchronization (DirSync) LDAP server extension control to search for changes on objects.

The synchronization process is defined in an agreement between an IdM server and an Active Directory domain controller. These servers are called peers. The agreement defines the information required to identify user entries that can be synchronized, such as the subtree to synchronize, and defines the configuration for attribute handling.

The synchronization process can be unidirectional or bidirectional. Some actions, however, such as adding a new user to the domain, can only be performed in the Windows domain and then synchronized to the IdM domain, and not vice versa. To prevent data corruption or read and write conflicts, you must configure only one directory synchronization service to create or remove user entries. You might want to select the Windows directory because in most environments it is the primary identity store. Either of the directories can modify entries.