1.2. Relationships Between Servers and Clients
IPA itself defines a domain, a group of machines that have shared configuration, policies, and identity stores. This shared configuration allows the machines (and users) within the domain to be aware of each other and operate together. This awareness can be used to enable cross-platform compatibility, like unifying Windows and Linux systems, or to enable infrastructure-wide single sign-on.
A client is simply any machine which is configured to operate within the IPA domain, using its Kerberos and DNS services, NTP settings, and certificate services. That's an important distinction: a client does not require a daemon or (necessarily) an installed product. It requires only system configurations which direct it to use IPA services.
For Red Hat Enterprise Linux systems, a certain number of platform tools are available for IPA to use, such as SSSD. These are IPA-enabled platform applications, which is simply a way of saying that they are aspects of the underlying platform that work with IPA services. Other tools, like certain PAM and NSS modules and IPA command-line utilities, are provided as IPA-specific packages that must be installed on the machine. These are IPA-related components.
Figure 1.1. Server and Client Interactions
IPA uses the local storage (cache) on a client to improve performance in a few ways:
- Store IPA information when the machine is offline.
- Keep information active beyond its normal timeout period if the client cannot access the central server. The cache is persistent even after rebooting the machine.
- Reduce the round-trip time of requests by checking information locally before looking at the server.
Information is stored either in an LDB database (similar to LDAP) or the local filesystem (as XML files), depending on the type of information.
- Identity information (about users, machines, and groups) is stored in the LDB database, which uses the same syntax as an LDAP directory. This identity information is originally stored in the IPA server's 389 Directory Server instance. Because this information changes frequently and is referenced frequently, it is important to be able to call the more current information quickly, which is possible using an LDB database on the client and the Directory Server on the server.
- Policy information is more static than identity information, and it can include configuration for SELinux or sudo. These policies are set globally on the server and then are propagated to the clients. On the client, the policy information is stored in the filesystem in XML files which can be downloaded and converted into a native file for whatever service is being managed.
A specific set of services on the IPA server interact with a subset of services and modules on the IPA client. A client is any machine (a host) which can retrieve a keytab or certificates from the IPA domain.
Figure 1.2. Interactions Between IPA Services
Figure 1.2, “Interactions Between IPA Services” shows that Red Hat Enterprise Linux uses two native daemons to interact with the IPA server:
- SSSD provides the user authentication for the machine and enforces host-based access control rules.
certmongermonitors and renews the certificates on the client. It can request new certificates for the services on the system, including virtual machines.
When a Red Hat Enterprise Linux client is added to the domain (enrolled), its SSSD and
certmonger are configured to connect to the IPA server and the required Kerberos keytab and host certificates are created. (The host certificate is not used directly by IPA; it may be used by other services, such as a web server.)
