1.2. The Identity Management Domain

The Identity Management (IdM) domain consists of a group of machines that share the same configuration, policies, and identity stores. The shared properties allow the machines within the domain to be aware of each other and operate together.
From the perspective of IdM, the domain includes the following types of machines:
  • IdM servers, which work as domain controllers
  • IdM clients, which are enrolled with the servers
IdM servers are also IdM clients enrolled with themselves: server machines provide the same functionality as clients.
IdM supports Red Hat Enterprise Linux machines as the IdM servers and clients.

Note

This guide describes using IdM in Linux environments. For more information on integration with Active Directory, see the Windows Integration Guide.

1.2.1. Identity Management Servers

The IdM servers act as central repositories for identity and policy information. They also host the services used by domain members. IdM provides a set of management tools to manage all the IdM-associated services centrally: the IdM web UI and command-line utilities.
For information on installing IdM servers, see Chapter 2, Installing and Uninstalling an Identity Management Server.
To support redundancy and load balancing, the data and configuration can be replicated from one IdM server to another: a replica of the initial server. You can configure servers and their replicas to provide different services to clients. For more details on IdM replicas, see Chapter 4, Installing and Uninstalling Identity Management Replicas.

1.2.1.1. Services Hosted by IdM Servers

Most of the following services are not strictly required to be installed on the IdM server. For example, services such as a certificate authority (CA), a DNS server, or a Network Time Protocol (NTP) server can be installed on an external server outside the IdM domain.
Kerberos KDC
IdM uses the Kerberos protocol to support single sign-on. With Kerberos, the user only needs to present the correct user name and password once. Then the user can access IdM services without the system prompting for the credentials again.
LDAP directory server
IdM includes an internal LDAP directory server instance where it stores all the IdM information, such as information related to Kerberos, user accounts, host entries, services, policies, DNS, and others.
The LDAP directory server instance is based on the same technology as Red Hat Directory Server. However, it is tuned to IdM-specific tasks.

Note

This guide refers to this component as Directory Server.
Certificate authority
In most deployments, an integrated certificate authority (CA) is installed with the IdM server. You can also install the server without the integrated CA if you create and provide all required certificates independently.

Note

This guide refers to this component as Certificate System when addressing the implementation and as certificate authority when addressing the services provided by the implementation.
For information relating to Red Hat Certificate System, a standalone Red Hat product, see Product Documentation for Red Hat Certificate System.
Domain Name System (DNS)
IdM uses DNS for dynamic service discovery. The IdM client installation utility can use information from DNS to automatically configure the client machine. After the client is enrolled in the IdM domain, it uses DNS to locate IdM servers and services within the domain.
Network Time Protocol
Many services require that servers and clients have the same system time, within a certain variance. For example, Kerberos tickets use time stamps to determine their validity and to prevent replay attacks. If the times between the server and client skew outside the allowed range, the Kerberos tickets are invalidated.
By default, IdM uses the Network Time Protocol (NTP) to synchronize clocks over a network. With NTP, a central server acts as an authoritative clock and the clients synchronize their times to match the server clock. The IdM server is configured as the NTP server for the IdM domain during the server installation process.

Note

Running an NTP server on an IdM server installed on a virtual machine can lead to inaccurate time synchronization in some environments. To avoid potential problems, do not run NTP on IdM servers installed on virtual machines. For more information on the reliability of an NTP server on a virtual machine, see this Knowledgebase solution.
The Identity Management Server: Unifying Services

Figure 1.1. The Identity Management Server: Unifying Services

1.2.2. Identity Management Clients

IdM clients are machines configured to operate within the IdM domain. They interact with the IdM servers to access domain resources. For example, they belong to the Kerberos domains configured on the servers, receive certificates and tickets issued by the servers, and use other centralized services for authentication and authorization.
An IdM client does not require dedicated client software to interact as a part of the domain. It only requires proper system configuration of certain services and libraries, such as Kerberos or DNS. This configuration directs the client machine to use IdM services.
For information on installing IdM clients, see Chapter 3, Installing and Uninstalling Identity Management Clients.

1.2.2.1. Services Hosted by IdM Clients

System Security Services Daemon
The System Security Services Daemon (SSSD) is a client-side application for caching credentials. Using SSSD on client machines is recommended because it simplifies the required client configuration. SSSD also provides additional features, for example:
  • Offline client authentication, ensured by caching credentials from centralized identity and authentication stores locally
  • Improved consistency of the authentication process, because it is not necessary to maintain both a central account and a local user account for offline authentication
  • Integration with other services, such as sudo
  • Host-based access control (HBAC) authorization
With SSSD, the IdM administrators can define all identity configuration centrally in the IdM server. Caching enables the local system to continue normal authentication operations if the IdM server becomes unavailable or if the client becomes offline.
For more information about SSSD, see the System-Level Authentication Guide. SSSD also supports Windows Active Directory (AD). For more information about using SSSD with AD, see the Windows Integration Guide.
certmonger
The certmonger service monitors and renews the certificates on the client. It can request new certificates for the services on the system.
For more information about certmonger, see the System-Level Authentication Guide.
Interactions Between IdM Services

Figure 1.2. Interactions Between IdM Services