Red Hat Summit Red Hat SummitSupportConsoleDevelopersStart a trialContact

Chapter 2. Migrating your IdM environment from RHEL 7 servers to RHEL 8 servers

To upgrade a RHEL 7 IdM environment to RHEL 8, you must first add new RHEL 8 IdM replicas to your RHEL 7 IdM environment, and then retire the RHEL 7 servers.

Warning
  • Performing an in-place upgrade of RHEL 7 IdM servers and IdM server nodes to RHEL 8 is not supported.

  • Migrating directly to RHEL 8 from RHEL 6 or earlier versions is not supported. To properly update your IdM data, you must perform incremental migrations.

    For example, to migrate a RHEL 6 IdM environment to RHEL 8:

    1. Migrate from RHEL 6 servers to RHEL 7 servers. See Migrating Identity Management from Red Hat Enterprise Linux 6 to Version 7.
    2. Migrate from RHEL 7 servers to RHEL 8 servers, as described in this section.
Important

RHEL 8 supports SPAKE and IdP pre-authentication, but RHEL 7 does not. Having RHEL 8 servers with SPAKE or IdP enabled in a RHEL 7 IdM deployment may lead to problems such as users not being able to log in. Therefore, migrate all servers in an IdM deployment as quickly as possible.

For more information, see Red Hat Knowledgebase solutions Pre-authentication failures in kerberos and Using 2FA/OTP authentication for AD trust users.

This procedure describes how to migrate all Identity Management (IdM) data and configuration from a Red Hat Enterprise Linux (RHEL) 7 server to a RHEL 8 server. You can also use this procedure to migrate from FreeIPA servers on non-RHEL Linux distributions to IdM on RHEL 8 servers.

The main migration procedure includes:

  1. Configuring a RHEL 8 IdM server and adding it as a replica to your current RHEL 7 IdM environment. For details, see Installing the RHEL 8 Replica.
  2. Making the RHEL 8 server the certificate authority (CA) renewal server. For details, see Assigning the CA renewal server role to the RHEL 8 IdM server.
  3. Stopping the generation of the certificate revocation list (CRL) on the RHEL 7 server and redirecting CRL requests to RHEL 8. For details, see Stopping CRL generation on a RHEL 7 IdM CA server.
  4. Starting the generation of the CRL on the RHEL 8 server. For details, see Starting CRL generation on the new RHEL 8 IdM CA server.
  5. Stopping and decommissioning the original RHEL 7 CA renewal server. For details, see Stopping and decommissioning the RHEL 7 server.

Additional procedures for large or complex deployments

The following optional procedures are strongly recommended for large, geographically distributed, or mission-critical IdM deployments to ensure topology health and prevent service disruption:

Before beginning your migration, review the strategy guidance and consider which optional procedures apply to your deployment:

In the following procedures:

  • rhel8.example.com is the RHEL 8 system that will become the new CA renewal server.

  • rhel7.example.com is the original RHEL 7 CA renewal server.

    If your IdM deployment does not use a certificate authority (CA), any IdM server running on RHEL 7 can be rhel7.example.com.

Migrating a large or geographically distributed Identity Management (IdM) topology requires additional planning to ensure service continuity. While the core migration steps (installing a new replica, establishing it as a CA renewal server, and decommissioning the old server) apply to all deployments, large environments benefit from stricter inventory and validation processes.

Migration workflow comparison

The following table highlights the recommended additional steps for large or complex topologies compared to a standard single-server or small-cluster migration.

Expand
StepStandard MigrationLarge/Complex Migration

1. Inventorying Topology

Optional.

Strongly Recommended. Document all server roles and replication agreements to ensure no critical service (CA, DNS, KRA, AD Trust) is lost during replica replacement.

2. Recording DNA ID Ranges

Optional.

Strongly Recommended. Record assigned ID ranges to prevent exhaustion if a server holding a large range is decommissioned without reassignment.

3. Reusing Server Hostname

Rarely needed.

Conditional. If reusing hostnames, wait for replication to fully converge before re-installing. Rapid removal and addition can cause conflicts in high-latency topologies.

4. Installing New Replica

Required.

Required. Ensure the new replica is installed with the same roles as the one it replaces. Run Healthcheck during verification to catch issues early.

5. Assigning CA Renewal Role

Required (if using integrated CA).

Required (if using integrated CA). Verify the role assignment replicates before proceeding.

6. Managing CRL Generation

Required (if using integrated CA).

Required (if using integrated CA). Stop CRL on old server, redirect requests, start on new server.

7. Updating Client Configuration

Automatic (mostly).

Manual updates may be needed. Clients pinned to specific servers in ipa.conf or sssd.conf must be updated to point to new replicas.

8. Decommissioning Old Server

Required.

Required. Verify no unique roles are lost and allow replication to converge.

Strategic considerations for large deployments

  • Maintain Redundancy: Ensure at least one other server provides critical services (CA, DNS, KRA, AD Trust) before decommissioning a replica.
  • Replication Lag: In geographically distributed deployments, allow additional time between topology changes for replication to converge. Rapid remove/add cycles can create conflicts that are difficult to resolve across high-latency links.
  • Batching: For very large topologies, migrate site-by-site, validating health after each wave. Avoid decommissioning all servers in a single site simultaneously.

On rhel7.example.com:

  1. Upgrade the system to the latest RHEL 7 version.
  2. Ensure that the domain level for your domain is set to 1. For more information, see Displaying and Raising the Domain Level in the Linux Domain Identity, Authentication, and Policy Guide for RHEL 7.

  3. Update the ipa-* packages to their latest version: 

    [root@rhel7 ~]# yum update ipa-*
    Warning

    When upgrading multiple Identity Management (IdM) servers, wait at least 10 minutes between each upgrade.

    When two or more servers are upgraded simultaneously or with only short intervals between the upgrades, there is not enough time to replicate the post-upgrade data changes throughout the topology, which can result in conflicting replication events.

On rhel8.example.com:

  1. Install the latest version of Red Hat Enterprise Linux on the system. For more information, see Interactively installing RHEL from installation media.

  2. Identify the time server rhel7.example.com is synchronized with: 

    [root@rhel7 ~]# ntpstat
synchronised to NTP server (ntp.example.com) at stratum 3
   time correct to within 42 ms
   polling server every 1024 s
    Important

    In RHEL 8, IdM does not provide its own time server: the installation of IdM on rhel8.example.com does not result in the installation of an NTP server on the host. Therefore, you need to use a separate NTP server, for example ntp.example.com. For more information, see Migrating to chrony and Time service requirements for IdM.

    While rhel7.example.com can be used in an NTP server role, you will decommission the server as part of the migration process. Therefore, rhel8.example.com needs to be synchronized directly with ntp.example.com instead. You can specify this during the client installation process.

  3. Enroll the system as an IdM client into the domain for which rhel7.example.com IdM server is authoritative. For more information, see Installing an IdM client. When installing the client, specify the time server from the previous step: 

    [root@rhel8]# ipa-client-install --mkhomedir --ntp-server ntp.example.com

    If you are using a pool of NTP servers, use the --ntp-pool option.

    If you do not specify an NTP server manually, it will be automatically set from DNS records. This can lead to rhel8.example.com synchronizing with rhel7.example.com. This will cause issues when the RHEL 7 server is decommissioned.

    If the RHEL8 system is already properly configured as an NTP client, you can use the --no-ntp option when performing the IdM client installation.

    Important

    Do not use single-label domain names, for example .company. Starting with RHEL 8, IDM does not accept single-labeled domain names and the domain name must be composed of one or more subdomains and a top level domain, for example example.com or company.example.com.

    If the existing domain is single-labeled, it is not possible to perform the migration using these instructions. In these cases, use Migrating an LDAP Server to Identity Management.

  4. Prepare the system for IdM server installation. See Preparing the system for IdM server installation.
  5. Authorize the system for the installation of an IdM replica. See Authorizing the installation of a replica on an IdM client.

  6. Update the ipa-* packages to their latest version: 

    [root@rhel7 ~]# yum update ipa-*
Note

For large or geographically distributed deployments, consider completing the following optional but recommended procedures before beginning the migration:

These steps help ensure service continuity and prevent issues during the migration.

Use this procedure to capture the current IdM server roles and replication layout before you replace replicas. This procedure is optional but strongly recommended, especially for large or complex topologies, to prevent role coverage gaps.

Prerequisites

  • You are logged in to an IdM server as an administrator.

Procedure

  1. List the servers in the topology and the roles enabled on each server: 

    [root@rhel7 ~]# ipa server-find --all
---------------------
2 IPA servers matched
---------------------
  dn: cn=ipa1.example.com,cn=masters,cn=ipa,cn=etc,dc=example,dc=com
  Server name: ipa1.example.com
  Managed suffixes: domain, ca
  Min domain level: 1
  Max domain level: 1
  Enabled server roles: AD trust agent, AD trust controller, CA server, DNS server, IPA master, KRA server

  dn: cn=ipa2.example.com,cn=masters,cn=ipa,cn=etc,dc=example,dc=com
  Server name: ipa2.example.com
  Managed suffixes: domain, ca
  Min domain level: 1
  Max domain level: 1
  Enabled server roles: AD trust agent, AD trust controller, CA server, IPA master
----------------------------
Number of entries returned 2
----------------------------

  2. Verify that the CA renewal master role is assigned to exactly one server: 

    [root@rhel7 ~]# ipa config-show | grep "CA renewal master"
IPA CA renewal master: ipa1.example.com

  3. Verify that the DNSSEC key master role is assigned to exactly one server: 

    [root@rhel7 ~]# ipa dnsconfig-show | grep 'DNSSec key master'
IPA DNSSec key master: ipa1.example.com
  4. Record which servers provide other critical roles (such as CA, DNS, KRA, AD trust agent, and AD trust controller). You will reference this list when assigning roles to new replicas or validating redundancy during migration.

  5. If your IdM deployment is in a trust with an Active Directory (AD) forest, plan to ensure that during the migration:

    1. At least one trust controller remains online at all times.
    2. Whenever possible, each replica also runs the trust agent so that clients can resolve AD users regardless of which server they contact.
  6. Review replication agreements and the site layout to confirm that each site keeps redundant connectivity throughout the migration: Replica topology examples.
  7. Ensure that the number of replication agreements per server aligns with the long-term guideline of four or fewer links: Guidelines for connecting IdM replicas in a topology.

2.4. Recording DNA ID ranges before migration
Copy link

Use this procedure to document the Distributed Numeric Assignment (DNA) ID ranges that are currently allocated so that you can reassign them after a server is removed during migration. Recording DNA ranges is optional but strongly recommended, especially for large or complex topologies, to prevent blocking user creation.

Prerequisites

  • You are logged in to an IdM server as an administrator.

Procedure

  1. On each server that will be decommissioned, display the DNA ID ranges currently allocated: 

    [root@rhel7 ~]# ipa-replica-manage dnarange-show

  2. Display the next DNA range queued for allocation so you know what will be assigned after the current sub-range is consumed: 

    [root@rhel7 ~]# ipa-replica-manage dnanextrange-show
  3. Record the collected ranges in your migration notes. You will reference these values when ensuring DNA range coverage on the new replica before decommissioning the old server. Losing a server that owns an unrecorded sub-range can block the creation of new users or groups.

Additional resources

Displaying the currently assigned DNA ID ranges

Assigning DNA ID ranges manually

2.5. Reusing an IdM server hostname safely
Copy link

Follow this procedure when you need to reuse an existing IdM server hostname for a new replica during migration. Hostname reuse is typically required when:

  • DNS or firewall rules are tightly coupled to specific hostnames
  • Client configurations explicitly reference the hostname that must be preserved
  • Network or security policies require specific server names

This procedure is optional; use it only when hostname reuse is necessary. For large or geographically distributed topologies, extra care is needed to prevent replication conflicts when reusing hostnames.

Prerequisites

  • You have administrative access to the IdM topology and to the server being replaced.
  • DNS records for the hostname can be updated if the IP address changes.
Warning

This procedure describes a specialized workflow for reusing an existing server hostname during migration. Only follow this procedure if you specifically need to preserve a hostname due to DNS, firewall rules, or client configuration requirements.

If you are performing a standard migration with new hostnames, skip this procedure and proceed directly to installing your new replica.

Procedure

  1. Remove the server from the topology on a different replica. For example, to remove rhel7.example.com: 

    [root@rhel8 ~]# ipa-replica-manage del rhel7.example.com --cleanup

    Confirm the command completes successfully and that the removal is replicated to the remaining servers.

  2. On the RHEL 7 host you are decommissioning, uninstall the IdM server to clean up services and certificates: 

    [root@rhel7 ~]# ipa-server-install --uninstall
  3. Allow replication to converge across all remaining servers before you reinstall a replica with the same hostname. In high-latency environments, wait for at least one full replication cycle and confirm the host no longer appears in ipa server-find output.
  4. After replication has fully converged and you have confirmed the old server no longer appears in the topology, proceed to install your new RHEL 8 replica using the reused hostname. See Installing the RHEL 8 replica.

  5. After installation completes, run IdM Healthcheck on the new RHEL 8 replica to verify that no replication conflicts were introduced: 

    [root@rhel8 ~]# ipa-healthcheck

    Pay particular attention to replication-related checks to ensure the hostname reuse did not cause conflicts.

2.6. Installing the RHEL 8 replica
Copy link

  1. List which server roles are present in your RHEL 7 environment: 

    [root@rhel7 ~]# ipa server-role-find --status enabled --server rhel7.example.com
----------------------
3 server roles matched
----------------------
  Server name: rhel7.example.com
  Role name: CA server
  Role status: enabled

  Server name: rhel7.example.com
  Role name: DNS server
  Role status: enabled

  Server name: rhel7.example.com
  Role name: NTP server
  Role status: enabled
[... output truncated ...]

  2. Optional: If you want to use the same per-server forwarders for rhel8.example.com that rhel7.example.com is using, view the per-server forwarders for rhel7.example.com: 

    [root@rhel7 ~]# ipa dnsserver-show rhel7.example.com
-----------------------------
1 DNS server matched
-----------------------------
  Server name: rhel7.example.com
  SOA mname: rhel7.example.com.
  Forwarders: 192.0.2.20
  Forward policy: only
--------------------------------------------------
Number of entries returned 1
--------------------------------------------------

  3. Install the IdM server on rhel8.example.com as a replica of the IdM RHEL 7 server, including all the server roles present on your rhel7.example.com except the NTP server role. To install the roles from the example above, use these options with the ipa-replica-install command:

    • --setup-ca to set up the Certificate System component

    • --setup-dns and --forwarder to configure an integrated DNS server and set a per-server forwarder to take care of DNS queries that go outside the IdM domain

      Note

      Additionally, if your IdM deployment is in a trust relationship with Active Directory (AD), add the --setup-adtrust option to the ipa-replica-install command to configure AD trust capability on rhel8.example.com.

      To set up an IdM server with the IP address of 192.0.2.1 that uses a per-server forwarder with the IP address of 192.0.2.20: 

      [root@rhel8 ~]# ipa-replica-install --setup-ca --ip-address 192.0.2.1 --setup-dns --forwarder 192.0.2.20

      You do not need to specify the RHEL 7 IdM server itself because if DNS is working correctly, rhel8.example.com will find it using DNS autodiscovery.

  4. Optional: Add an _ntp._udp service (SRV) record for your external NTP time server to the DNS of the newly-installed IdM server, rhel8.example.com. Doing this is recommended because IdM in RHEL 8 does not provide its own time service. The presence of the SRV record for the time server in IdM DNS ensures that future RHEL 8 replica and client installations are automatically configured to synchronize with the time server used by rhel8.example.com. This is because ipa-client-install looks for the _ntp._udp DNS entry unless --ntp-server or --ntp-pool options are provided on the install command-line interface (CLI).

Verification

  1. Verify that the IdM services are running on rhel8.example.com: 

    [root@rhel8 ~]# ipactl status
Directory Service: RUNNING
[... output truncated ...]
ipa: INFO: The ipactl command was successful

  2. Run IdM Healthcheck on rhel8.example.com to validate services, replication, and certificate health: 

    [root@rhel8 ~]# ipa-healthcheck

    If Healthcheck reports warnings or errors, investigate and resolve them before decommissioning any RHEL 7 servers. For targeted replication tests, you can run: 

    [root@rhel8 ~]# ipa-healthcheck --source=ipahealthcheck.ds.replication --source=ipahealthcheck.ipa.topology

  3. Verify that server roles for rhel8.example.com are the same as for rhel7.example.com except the NTP server role: 

    [root@rhel8 ~]$ kinit admin
[root@rhel8 ~]$ ipa server-role-find --status enabled --server rhel8.example.com
----------------------
2 server roles matched
----------------------
  Server name: rhel8.example.com
  Role name: CA server
  Role status: enabled

  Server name: rhel8.example.com
  Role name: DNS server
  Role status: enabled

  4. Optional: Display details about the replication agreement between rhel7.example.com and rhel8.example.com: 

    [root@rhel8 ~]# ipa-csreplica-manage list --verbose rhel8.example.com
Directory Manager password:

rhel7.example.com
last init status: None
last init ended: 1970-01-01 00:00:00+00:00
last update status: Error (0) Replica acquired successfully: Incremental update succeeded
last update ended: 2019-02-13 13:55:13+00:00

  5. Optional: If your IdM deployment is in a trust relationship with AD, verify that it is working:

    1. link: Verify the Kerberos configuration

    2. Attempt to resolve an AD user on rhel8.example.com: 

      [root@rhel8 ~]# id aduser@ad.domain

  6. Verify that rhel8.example.com is synchronized with the NTP server: 

    [root@rhel8 ~]# chronyc tracking
Reference ID    : CB00710F (ntp.example.com)
Stratum         : 3
Ref time (UTC)  : Tue Nov 16 09:49:17 2021
[... output truncated ...]

Follow this procedure to make the RHEL 8 server the certificate authority (CA) renewal server.

Note

Follow these steps only if your IdM deployment uses an embedded certificate authority (CA).

On rhel8.example.com, configure rhel8.example.com as the new CA renewal server:

  1. Configure rhel8.example.com to handle CA subsystem certificate renewal: 

    [root@rhel8 ~]# ipa config-mod --ca-renewal-master-server rhel8.example.com
  ...
  IPA masters: rhel7.example.com, rhel8.example.com
  IPA CA servers: rhel7.example.com, rhel8.example.com
  IPA NTP servers: rhel7.example.com, rhel8.example.com
  IPA CA renewal master: rhel8.example.com

    The output confirms that the update was successful.

  2. On rhel8.example.com, enable the certificate updater task:

    1. Open the /etc/pki/pki-tomcat/ca/CS.cfg configuration file for editing.
    2. Remove the ca.certStatusUpdateInterval entry, or set it to the desired interval in seconds. The default value is 600.
    3. Save and close the /etc/pki/pki-tomcat/ca/CS.cfg configuration file.

    4. Restart IdM services: 

      [user@rhel8 ~]$ ipactl restart

  3. On rhel7.example.com, disable the certificate updater task:

    1. Open the /etc/pki/pki-tomcat/ca/CS.cfg configuration file for editing.

    2. Change ca.certStatusUpdateInterval to 0, or add the following entry if it does not exist: 

      ca.certStatusUpdateInterval=0
    3. Save and close the /etc/pki/pki-tomcat/ca/CS.cfg configuration file.

    4. Restart IdM services: 

      [user@rhel7 ~]$ ipactl restart
Note

Follow these steps only if your IdM deployment uses an embedded certificate authority (CA).

Follow this procedure to stop generating the Certificate Revocation List (CRL) on the rhel7.example.com CA server using the ipa-crlgen-manage command.

Prerequisites

  • You must be logged in as root.

Procedure

  1. Optional: Check if rhel7.example.com is generating the CRL: 

    [root@rhel7 ~]# ipa-crlgen-manage status
CRL generation: enabled
Last CRL update: 2019-10-31 12:00:00
Last CRL Number: 6
The ipa-crlgen-manage command was successful

  2. Stop generating the CRL on the rhel7.example.com server: 

    [root@rhel7 ~]# ipa-crlgen-manage disable
Stopping pki-tomcatd
Editing /var/lib/pki/pki-tomcat/conf/ca/CS.cfg
Starting pki-tomcatd
Editing /etc/httpd/conf.d/ipa-pki-proxy.conf
Restarting httpd
CRL generation disabled on the local host. Please make sure to configure CRL generation on another master with ipa-crlgen-manage enable.
The ipa-crlgen-manage command was successful

Verification

  1. Check if the rhel7.example.com server stopped generating the CRL: 

    [root@rhel7 ~]# ipa-crlgen-manage status

The rhel7.example.com server stopped generating the CRL. The next step is to enable generating the CRL on rhel8.example.com.

Note

Follow these steps only if your IdM deployment uses an embedded certificate authority (CA).

Prerequisites

  • You must be logged in as root on the rhel8.example.com machine.

Procedure

  1. To start generating CRL on rhel8.example.com, use the ipa-crlgen-manage enable command: 

    [root@rhel8 ~]# ipa-crlgen-manage enable
Stopping pki-tomcatd
Editing /var/lib/pki/pki-tomcat/conf/ca/CS.cfg
Starting pki-tomcatd
Editing /etc/httpd/conf.d/ipa-pki-proxy.conf
Restarting httpd
Forcing CRL update
CRL generation enabled on the local host. Please make sure to have only a single CRL generation master.
The ipa-crlgen-manage command was successful

  2. To check if CRL generation is enabled, use the ipa-crlgen-manage status command: 

    [root@rhel8 ~]# ipa-crlgen-manage status
CRL generation: enabled
Last CRL update: 2019-10-31 12:10:00
Last CRL Number: 7
The ipa-crlgen-manage command was successful

Use this procedure to update clients that do not rely solely on DNS service discovery after you replace or decommission IdM replicas. Updating pinned clients is optional but strongly recommended for large or complex topologies where static configuration is common.

Prerequisites

  • You have root access to each client that requires updates.
  • Replacement IdM servers are in service and reachable.

Procedure

  1. Update the system resolvers on affected clients so they point to the current IdM DNS servers. Adjust /etc/resolv.conf or your network configuration tooling to remove references to retired servers.

  2. If the client uses the fallback enrollment server defined in /etc/ipa/default.conf, replace the hostname in both of the following parameters with an active IdM server: 

    xmlrpc_uri = https://ipa_new.example.com/ipa/xml
server = ipa_new.example.com

  3. Review the ipa_server parameter in /etc/sssd/sssd.conf:

    • If it lists specific servers, update the list to include only active replicas or switch to SRV-only discovery by using srv.
    • If it references the retired hostname, replace it with the new server names.

  4. Restart SSSD to apply the updates: 

    [root@client ~]# systemctl restart sssd
  5. Test authentication and lookups from the client to confirm it can reach the updated servers.

  1. Ensure that all data, including the latest changes, have been correctly migrated from rhel7.example.com to rhel8.example.com. For example:

    1. Add a new user on rhel7.example.com: 

      [root@rhel7 ~]# ipa user-add random_user
First name: random
Last name: user

    2. Check that the user has been replicated to rhel8.example.com: 

      [root@rhel8 ~]# ipa user-find random_user
--------------
1 user matched
--------------
  User login: random_user
  First name: random
  Last name: user

  2. Ensure that a Distributed Numeric Assignment (DNA) ID range is allocated to rhel8.example.com. If you recorded DNA ranges earlier (see Recording DNA ID ranges before migration), you can reference those values when reassigning ranges. Use one of the following methods:

    • Activate the DNA plug-in on rhel8.example.com directly by creating another test user: 

      [root@rhel8 ~]# ipa user-add another_random_user
First name: another
Last name: random_user

    • Assign a specific DNA ID range to rhel8.example.com:

      1. On rhel7.example.com, display the IdM ID range: 

        [root@rhel7 ~]# ipa idrange-find
----------------
3 ranges matched
----------------
  Range name: EXAMPLE.COM_id_range
  First Posix ID of the range: 196600000
  Number of IDs in the range: 200000
  First RID of the corresponding RID range: 1000
  First RID of the secondary RID range: 100000000
  Range type: local domain range

      2. On rhel7.example.com, display the allocated DNA ID ranges: 

        [root@rhel7 ~]# ipa-replica-manage dnarange-show
rhel7.example.com: 196600026-196799999
rhel8.example.com: No range set

      3. Reduce the DNA ID range allocated to rhel7.example.com so that a section becomes available to rhel8.example.com: 

        [root@rhel7 ~]# ipa-replica-manage dnarange-set rhel7.example.com 196600026-196699999

      4. Assign the remaining part of the IdM ID range to rhel8.example.com: 

        [root@rhel7 ~]# ipa-replica-manage dnarange-set rhel8.example.com 196700000-196799999

  3. Stop all IdM services on rhel7.example.com to force domain discovery to the new rhel8.example.com server. 

    [root@rhel7 ~]# ipactl stop
Stopping CA Service
Stopping pki-ca:                                           [  OK  ]
Stopping HTTP Service
Stopping httpd:                                            [  OK  ]
Stopping MEMCACHE Service
Stopping ipa_memcached:                                    [  OK  ]
Stopping DNS Service
Stopping named: .                                          [  OK  ]
Stopping KPASSWD Service
Stopping Kerberos 5 Admin Server:                          [  OK  ]
Stopping KDC Service
Stopping Kerberos 5 KDC:                                   [  OK  ]
Stopping Directory Service
Shutting down dirsrv:
    EXAMPLE-COM...                                         [  OK  ]
    PKI-IPA...                                             [  OK  ]

    After this, the ipa utility will contact the new server through a remote procedure call (RPC).

  4. Remove the RHEL 7 server from the topology by executing the removal commands on the RHEL 8 server. For details, see Uninstalling an IdM server.

Additional resources

Red Hat logoGithubredditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust. Explore our recent updates.

Legal Notice

Theme

© 2026 Red HatBack to top