Red Hat Summit Red Hat SummitSupportConsoleDéveloppeursCommencer un essaiContact

Ce contenu n'est pas disponible dans la langue sélectionnée.

Chapter 4. Migrating from one IdM server to another

The ipa-migrate tool enables you to migrate all Identity Management (IdM) data, including all configurations, schema, and database content, from one IdM server to another. This tool is useful, for example, for moving an IdM deployment from a development or staging environment to a production environment, or for migrating data between two production servers.

4.1. IdM to IdM migration
Copier lien

The ipa-migrate admin tool is a standalone client tool for migrating IdM data between two servers. You can use it on a new, local IdM server to transfer data from the original, remote IdM server.

You can use ipa-migrate to transfer most of the data from the remote server:

  • Schema: All LDAP object classes and attributes.
  • Configuration: Core Directory Server settings (dse.ldif), including performance tuning, security settings, plugins, and database settings.
  • Database: Most subtrees and entries, including users, groups, roles, hosts, services, sudo rules, HBAC rules, and DNS records (optional).

However, for security reasons, some items are excluded:

  • Kerberos master key
  • Self-signed CA certificates and KRA keys
  • The admin and Directory Manager passwords
  • Data stored in Custodia

You can perform the migration online, using an LDAP connection, or offline, using LDIF files from the remote server. You can also combine the online and offline methods by using a mixed approach. For large databases, a mixed approach is often the most efficient. For example, you can migrate the configuration and schema online and then use an LDIF file for the database migration, which is faster and more stable than transferring thousands of entries over the network.

Before committing to a migration, you can perform a dry run to preview the changes without writing any data to the new server. You can also record the LDAP operations to an LDIF file for detailed inspection or for replaying the migration at a later time.

The ipa-migrate tool offers the following migration modes:

  • Production mode

    This mode assumes the remote server is a fully functional, production environment. It migrates all data, including DNA ranges, IDs, and SIDs, as is.

  • Staging mode

    This mode is intended for migrating from a staging environment. It does not migrate DNA ranges and ID attributes like uidNumber and gidNumber, but regenerates them on the new server.

The migration process automatically converts the remote server’s realm, domain, and suffixes to match the new local server’s configuration. You can choose whether to migrate ID ranges, and you have the option to skip migrating DNS records, configuration, or schema. Using the tool, you can also include non-IdM content stored in the database tree by specifying the subtree in a command-line option.

After a successful migration, you must re-enroll IdM clients to the new deployment, and users must reset their passwords to generate new Kerberos keys.

4.2. Migrating an IdM environment from staging to production
Copier lien

Use this procedure to migrate a complete Identity Management (IdM) environment from a staging server to a new production server. This example uses a mixed migration approach, where the database is migrated offline using an LDIF file for improved performance and stability, while the configuration and schema are migrated online. The migration is performed in staging-mode to ensure that identity numbers (UIDs/GIDs) are regenerated for the new production environment.

Prerequisites

  • You are using RHEL 9.7 or later.

  • On the new production (local) server:

    • You have performed a standard installation of IdM.
    • The IdM domain and realm are set to their final production values.

  • On the staging (remote) server:

    • You have root access to export the user database.
    • You have the Directory Manager password.

Procedure

  1. On the remote staging server, for example remote.server.com, export the userRoot database to an LDIF file, such as userroot.ldif:

    1. Stop the DS instance: 

      # dsctl slapd-EXAMPLE-COM stop

    2. Export the database: 

      # dsctl slapd-EXAMPLE-COM db2ldif userroot /root/userroot.ldif

    3. Restart the DS instance: 

      # dsctl slapd-EXAMPLE-COM start
  2. Copy the userroot.ldif to the new local production server, for example to /root/userroot.ldif.

  3. On the local production server, execute a dry run of the migration to validate the process and preview changes without writing any data. Use stage-mode to ensure that DNA ranges and ID attributes are reset for the new production environment: 

    # ipa-migrate stage-mode remote.server.com --db-ldif=/root/userroot.ldif --dryrun
  4. Review the output to confirm that the tool identifies the correct entries for migration.

  5. Execute the migration command without the`--dryrun` option. You will be prompted for the Directory Manager password for the remote server: 

    # ipa-migrate stage-mode remote.server.com --db-ldif=/root/userroot.ldif
    Note

    The migration process includes running the ipa-server-upgrade task, which may take a significant amount of time depending on the size of your database.

Verification

  1. On the new production server, verify that the IdM services are running correctly: 

    # ipactl status
  2. Confirm that IdM data, such as users, groups, and sudo rules, has been successfully migrated using ipa user-find and ipa sudorule-find.
Note

The primary log file for the migration tool is located at /var/log/ipa-migrate.log. This file is appended to on each run, preserving the history of multiple migration attempts.

Next steps

  1. Re-enroll clients: All IdM clients that were connected to the old staging server must be re-enrolled into the new production IdM deployment. You can follow the steps in Re-enrolling na IdM client.
  2. Migrate user passwords: Users must log in to generate new Kerberos keys, as passwords are not migrated directly. Inform your users about the need to reset their passwords upon their first login to the new production environment. See Managing user passwords in IdM.

Additional information

Red Hat logoGithubredditYoutubeTwitter

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Nous aidons les utilisateurs de Red Hat à innover et à atteindre leurs objectifs grâce à nos produits et services avec un contenu auquel ils peuvent faire confiance. Découvrez nos récentes mises à jour.

Rendre l’open source plus inclusif

Red Hat s'engage à remplacer le langage problématique dans notre code, notre documentation et nos propriétés Web. Pour plus de détails, consultez le Blog Red Hat.

À propos de Red Hat

Nous proposons des solutions renforcées qui facilitent le travail des entreprises sur plusieurs plates-formes et environnements, du centre de données central à la périphérie du réseau.

Theme

© 2026 Red HatRetour au début