此内容没有您所选择的语言版本。
1.3. Relationships Between Servers and Clients
Identity Management 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.
1.3.1. About IdM Servers and Replicas
Identity Management works by having identified servers which are the master stores of information for user and machine identities and domain-wide policies. These servers host domain-related services such as certificate authorities, NTP, Kerberos, SSH, and DNS. The server also acts as a central repository of identity and policy information.
Clients interact indirectly with IdM servers when they attempt to access domain resources, such as fileshares, services, remote machines, or authentication (through SSSD and Kerberos).
As said, an IdM server is a controller for a lot of associated services. While a number of those services are supported, most of them are not required. For example, a server may have a CA, a DNS server, or an NTP server — or it can be installed without those services.
Once an IdM server is set up, its configuration can be copied and used as the basis for another IdM server. When an IdM server is copied, that copy is called a replica.
Note
The only real difference between an IdM server and an IdM replica is that a server is a new installation — so that it defines the domain configuration — and a replica is based on an existing server and existing domain configuration.
Once an instance is configured, servers and replicas are basically identical in functionality and behavior within the IdM domain.
There is a good deal of flexibility in the IdM server (and replica) topology. For example, Server A can be installed with a CA and DNS services, while Replica A can be based on Server A's configuration but not host either DNS or CA services. Replica B can be added to the domain, also without CA or DNS services. At any time in the future, a CA or DNS service can be created and configured on Replica A or Replica B.
Servers and replicas both use underlying LDAP directories to store user and host entries, configuration data, policy configuration, and keytabs, certificates, and keys. Servers and replicas propagate data among each other through multi-master replication agreements. Replication agreements are configured for all LDAP backends as well as the LDAP subtrees used by Dogtag Certificate System. Both servers and replicas are masters (peers) in the replication topology.
Because the servers within the IdM domain are all LDAP peer servers, the replication topology must conform to the topology limits of a 389 Directory Server domain. This means that there can be no more than 20 peer servers in the IdM domain. Planning the server/replica topology is described more in Section 4.1, “Planning the Server/Replica Topologies”.
Figure 1.2. Server and Replica Interactions
Note
The replication topology essentially creates a cloud of IdM servers. One benefit of a server domain is automatic load balancing, using the SRV records in DNS. The SRV record sets the priority order that servers and replicas are contacted, while weight distributes the load between servers/replicas with the same priority. The server and replica DNS entries can be edited to change the load balancing, which is covered in Example 17.9, “SRV Record” and Section 28.4.3, “Changing Load Balancing for IdM Servers and Replicas”.
1.3.2. About IdM Clients
A client is simply any machine which is configured to operate within the IdM 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 IdM services.
For Red Hat Enterprise Linux systems, a certain number of platform tools are available for IdM to use, such as the System Security Services Daemon (SSSD). IdM-enabled platform applications are aspects of the underlying platform that work with IdM services. Other tools, like certain PAM and NSS modules and IdM command-line utilities, are provided by Identity Management itseld as IdM-specific packages that must be installed on the machine. These are IdM components, rather than platform components used by Identity Management.
Figure 1.3. Server and Client Interactions
IdM uses the local storage (cache) on a client to improve performance in a few ways:
- Store IdM 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 IdM 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 IdM server interact with a subset of services and modules on the IdM client. A client is any machine (a host) which can retrieve a keytab or certificates from the IdM domain.
Figure 1.4. Interactions Between IdM Services
Figure 1.4, “Interactions Between IdM Services” shows that Red Hat Enterprise Linux uses two native daemons to interact with the IdM 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 IdM server and the required Kerberos keytab and host certificates are created. (The host certificate is not used directly by IdM; it may be used by other services, such as a web server.)
