Red Hat Security: Identity Management and Authentication
Abstract
| Goal |
Implement continuous functionality and high availability of IdM services in single-site and geographically distributed topologies. |
| Objectives |
|
| Sections |
|
| Lab |
|
Create an IdM topology by establishing replication agreements, manage the replication topology with Ansible, and promote and demote hidden replicas.
IdM can provide a resilient and highly performant service through the use of multiple servers, or replicas. Each server has a read/write copy of the directory, and any changes it makes must be communicated to the other servers. The way that administrators structure communication between the servers is known as the replication topology. Red Hat currently supports up to 60 replicas in an IdM topology.
When a replica is created, a replication agreement is also created between an existing IdM server and the new replica. This replication agreement ensures that the replica and the existing server keep each other updated with any changes made, and that there is no break in the replication topology. A replication agreement consists of one or more topology segments.
A topology segment is a connection from one server to another for a single topology suffix. Data replication always occurs in both directions.
Topology suffixes consist of two types of data that could replicate between IdM servers:
Domain data from the directory service.
Certificate data from the certificate service.
[user@host ~]$ ipa topologysuffix-find
---------------------------
2 topology suffixes matched
---------------------------
Suffix name: ca
Managed LDAP suffix DN: o=ipaca
Suffix name: domain
Managed LDAP suffix DN: dc=lab,dc=example,dc=com
----------------------------
Number of entries returned 2
----------------------------You can manage the IdM topology from the web UI, from the command line, or by using Ansible.
The IdM web UI enables administrators to manage the replication topology graphically from → → .
You can hover over a node, click the domain or ca suffix, and then select a second node as the other end of the new topology segment.
Enter the required segment name when prompted, and then click .
To delete a topology segment, select it and click . In the confirmation window, click .
You can use the ipa command-line client to find, view, add, and delete topology segments.
After the subcommand, you must specify the domain or ca suffix, and then any relevant options.
In a topology segment, one server is referred to as the left node, and the other as the right node.
The following example lists all topology segments for the domain suffix:
[user@host ~]$ ipa topologysegment-find domain
------------------
3 segments matched
------------------
Segment name: server.example.com-to-replica.example.com
Left node: server.example.com
Right node: replica.example.com
Connectivity: both
...output omitted...Adding topology segments requires options for the left and right nodes.
The following example illustrates creating a segment between server4 and server5:
[user@host ~]$ipa topologysegment-add domain \server4.example.com-to-server5.example.com \--leftnode=server4.example.com \--rightnode=server5.example.com--------------------------------------------------------------- Added segment "server4.example.com-to-server5.example.com" --------------------------------------------------------------- Segment name: server4.example.com-to-server5.example.com Left node: server4.example.com Right node: server5.example.com Connectivity: both
In this example, the segment created previously is deleted.
[user@host ~]$ipa topologysegment-del \domain server4.example.com-to-server5.example.com----------------------------------------------------------------- Deleted segment "server4.example.com-to-server5.example.com" -----------------------------------------------------------------
The freeipa.ansible_freeipa collection includes the ipatopologysegment module.
The following example task ensures that a topology segment for the domain suffix exists between server4 and server5:
- name: Add topology segment from server4 to server5
freeipa.ansible_freeipa.ipatopologysegment:
password: "{{ ipaadmin_password }}"
suffix: domain
left: server4.example.com
right: server5.example.com
state: presentRed Hat provides a utility that helps administrators to troubleshoot an IdM installation.
By installing the ipa-healthcheck package, administrators can troubleshoot the following issues:
Replication issues
Certificate validity
Certificate Authority infrastructure issues
IdM and Active Directory trust issues
File permissions and ownership settings
The health check generates output in two formats:
json. Machine-readable output inJSONformat (default)human. Human-readable output
You can specify the output format with the output-type option.
You can specify a different file destination with the --output-file option.
A health check returns one of the following results:
-
SUCCESS Configured as expected.
-
WARNING This is not an error, but you should review this result.
-
ERROR Not configured as expected.
-
CRITICAL Not configured as expected, with a high possibility of impact.
When designing a replication topology, Red Hat recommends that you take the following guidelines into account. These guidelines help to ensure that the loss of a single node or data center does not affect replication between the remaining servers.
Within a single data center, you should ensure that at least two replication agreements exist for each server if you have more than two servers. In the event of a single server failure, replication can continue through alternative paths. Creating more than four replication agreements for a server does not noticeably increase resilience, but can start to adversely affect server performance.
When planning replica numbers for a single location, you should include one replica for every 2000 to 3000 clients, plus one for redundancy. For example, to support 5000 users, install three replicas. By using three replicas, the loss of a single replica would not reduce performance.
A tight cell is a resilient arrangement for a single location and uses four servers with replication agreements from each server to all other servers. Each server can add one more replication agreement to another data center without exceeding the four replication agreement recommendation.
You should configure at least two replication agreements between a pair of data centers. Use two pairs of servers to prevent isolation of the whole data center in the event of a single server failure.
Connecting a data center to at least two others enables replication if an entire site is offline.
Hidden Replicas
One of the key operations for an IdM domain is backing up the LDAP directory server. However, because backing up the directory server requires stopping all IdM services, it can disrupt clients who are accessing this server.
The hidden replica feature was designed to avoid service disruption.
When configuring a replica, the installation creates service records (SRV) in DNS, allowing clients to detect the replica and its services. A hidden replica is an IdM server that has all services running and available. It has no SRV records in DNS, however, and the LDAP server functions are not enabled.
Because no clients use a hidden replica, administrators can shut down services on this host without affecting any clients.
Use the --hidden-replica option during replica installation to prevent the creation of SRV records.
[user@host ~]$ ipa-replica-install --hidden-replica
...output omitted...Existing servers can be hidden or advertised as required by modifying the server state.
[user@host ~]$ipa server-state server.example.com --state=hidden...output omitted... [user@host ~]$ipa server-state server.example.com --state=enabled...output omitted...
References
Further information is available in the Managing Replication Topology chapter in the Managing replication in Identity Management at https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html-single/managing_replication_in_identity_management/index#assembly_managing-replication-topology_managing-replication-in-idm
