Red Hat Security: Identity Management and Authentication

You can install a replica on a machine that is not part of the IdM domain. The replica installation process configures the machine as an IdM client first and then configures it as a replica server.

You can also configure an existing IdM client to be a replica. You must first grant privileges to the client before it can be configured as a replica. You can grant privileges to the client by providing the credentials of a privileged user or by adding the client to the ipaservers group.

Whichever method you choose, replica installation or configuring an existing client, the replica machine is always configured as a client first and then as a replica.

In an IdM infrastructure that has FIPS mode enabled, clients are not mandated to enable FIPS mode to interact with the IdM services. To configure a client as a replica in a FIPS-enabled infrastructure, however, you must ensure that the client has FIPS mode enabled. In this scenario, Red Hat recommends enabling FIPS mode right after the client OS installation. This could avoid a situation where non-FIPS compliant cryptography is used in the system.

Similarly, a FIPS-enabled client cannot be configured as a replica in a non-FIPS IdM infrastructure.

You can use server roles to configure a replica to host specific services. Depending on the service, the replica might only run the service by taking it over from another server. For this reason, you must ensure that during installation the replica mirrors the configuration of existing services. For example, if you configure a replica to host the CA service, then the CA configuration of the replica must mirror the CA configuration of the IdM server. The replica cannot have an external CA configured if the IdM server has an integrated CA service, and vice versa.

You can view the enabled roles in a replica server by using the ipa server-show command.

The installation requirements for replicas are the same as for IdM servers. For more information about IdM server installation requirements, refer to the the section called “ Installing an Identity Management Server ” section.

A replica system must use the same or a later IdM package version as the original server, to enable the replica to communicate and replicate with it.

You can install CA or DNS services on the replica, just as you can for IdM servers. If you have an integrated DNS in your topology, then you might want to configure DNS on at least one replica in each geographical location. This configuration is not a requirement but it ensures that the service is redundant. On the other hand, if you configure all replicas to provide DNS, the DNS zone replication might use unnecessary network bandwidth.

In this scenario, you choose to install the DNS service on the replica to have a redundant, load-balanced DNS.

The ipa-server package ensures that the dependencies for the replica installation are installed. However, you use the ipa-replica-install command to install the replica because it provides replica-specific installation options. Also, the ipa-replica-install command requires an existing IdM domain.

[root@replica ~]# dnf install ipa-server ipa-server-dns
...output omitted...

The freeipa-ldap and freeipa-ldaps services contain the ports needed to enable communication to and from the replica machine. You must open these firewall ports and ensure that the ports remain open after a system reboot. You can review the ports related to a service by using the firewall-cmd --permanent --service --get-ports command.

[root@replica ~]# firewall-cmd --permanent --service freeipa-ldaps --get-ports
80/tcp 443/tcp 88/tcp 88/udp 464/tcp 464/udp 123/udp 636/tcp
[root@replica ~]# firewall-cmd --add-service=freeipa-ldap --permanent
success
[root@replica ~]# firewall-cmd --add-service=freeipa-ldaps --permanent
success
[root@replica ~]# firewall-cmd --reload
success

You must also create the DNS record for the replica machine.

Similarly to many ipa commands, the ipa dnsrecord-add command without options or arguments can interactively prompt for the information of the DNS record to create. Some options, however, are not available in interactive mode. For example, the --a-create-reverse option, not available in interactive mode, creates the reverse DNS record for the given IP address.

[user@idm ~]$ kinit admin
Password for admin@LAB.EXAMPLE.COM: redhat123
[user@idm ~]$ ipa dnsrecord-add lab.example.com replica --a-rec=172.25.250.10 \
  --a-create-reverse
  Record name: replica
  A record: 172.25.250.10

The ipa-replica-install command requires access to the IdM server for the installation process. If the machine is not a member of the IdM domain, then you must provide a way to authenticate the machine.

You can install a replica on a non-domain machine by using a one-time password or by using a principal's credential.

You can configure an existing IdM client as a replica by using the ipa-replica-install command. Because this method uses a privileged principal authentication, you do not need to add the host to the ipaservers host group.

[root@client ~]# ipa-replica-install -w RedHat123^

By default, this command expects the admin user password. To use another user, you can use the --principal option or authenticate before running the ipa-replica-install command by using the kinit command.

You can configure the replica as a hidden replica during installation by adding the --hidden-replica option to the ipa-replica-install command.

The SRV record creation is omitted when installing a hidden replica, which makes the replica unusable by clients. You can use a hidden replica to make backups, or to perform bulk loads or extensive API queries.

You can enable a hidden replica for it to be visible to clients. You can use the ipa server-state --state=enabled command to enable a hidden replica. To hide a replica, define the replica state as hidden. Some roles might be removed when you hide a replica.

[root@idm ~]# ipa server-state client.lab.example.com --state=enabled
-------------------------------------------------
Changed server state of "client.lab.example.com".
-------------------------------------------------
[root@idm ~]# ipa server-state client.lab.example.com --state=hidden
-------------------------------------------------
Changed server state of "client.lab.example.com".
-------------------------------------------------

On the replica machine, use the ipa-server-install --uninstall command to remove the components and configuration. Back up any information that you might need, and ensure that DNS and CA services in the IdM topology are not affected by the replica removal.

[root@replica ~]# ipa-server-install --uninstall

On an IdM server, use the ipa server-del command to delete the replica from the topology. To avoid the undesired reuse of the machine as a replica, delete the DNS records related to the replica.

[user@idm ~]$ ipa server-del replica.lab.example.com
[user@idm ~]$ ipa dnsrecord-del lab.example.com replica
No option to delete specific record provided.
Delete all? Yes/No (default No): yes
-------------------------
Deleted record "replica"
-------------------------

You can also remove existing replication agreements by using the ipa-replica-manage del command.

[user@idm ~]$ ipa-replica-manage del replica.lab.example.com --force
Updating DNS system records
ipa: WARNING: Ignoring topology connectivity errors.
ipa: WARNING: Failed to cleanup replica.lab.example.com DNS entries: no matching entry found
ipa: WARNING: You may need to manually remove them from the tree
---------------------------------------------
Deleted IPA server "replica.lab.example.com"
---------------------------------------------