Product SiteDocumentation Site

Chapter 17. Migrating from an LDAP Directory to FreeIPA

17.1. An Overview of LDAP to FreeIPA Migration
17.1.1. Planning the Client Configuration
17.1.2. Planning Password Migration
17.1.3. Migration Considerations and Requirements
17.2. Scenario 1: Using SSSD as Part of Migration
17.3. Scenario 2: Migrating an LDAP Server Directly to FreeIPA
When an infrastructure has previously deployed an LDAP server for authentication and identity lookups, it is possible to migrate the user data, including passwords, to a new FreeIPA instance, without losing user or password data.
FreeIPA has migration tools to help move directory data and only requires minimal updates to clients. However, the migration process assumes a very simple deployment scenario (one LDAP directory namespace to one FreeIPA namespace).

17.1. An Overview of LDAP to FreeIPA Migration

The actual migration part of moving from an LDAP server to FreeIPA — the process of moving the data from one server to the other — is fairly straightforward. The process is simple: move data, move passwords, and move clients.
The crucial part of migration is not data migration; it is deciding how clients are going to be configured to use FreeIPA. For each client in the infrastructure, you need to decide what services (such as Kerberos and SSSD) are being used and what services can be used in the final, FreeIPA deployment.
A secondary, but significant, consideration is planning how to migrate passwords. FreeIPA requires Kerberos hashes for every user account in addition to passwords. Some of the considerations and migration paths for passwords are covered in Section 17.1.2, “Planning Password Migration”.

17.1.1. Planning the Client Configuration

FreeIPA can support a number of different client configurations, with varying degrees of functionality, flexibility, and security. Decide which configuration is best for each individual client based on its operating system, functional area (such as development machines, production servers, or user laptops), and your IT maintenance priorities.


The different client configurations are not mutually exclusive. Most environments will have a mix of different ways that clients use to connect to the FreeIPA domain. Administrators must decide which scenario is best for each individual client. Initial Client Configuration (Pre-Migration)

Before deciding where you want to go with the client configuration in FreeIPA, first establish where you are before the migration.
The initial state for almost all LDAP deployments that will be migrated is that there is an LDAP service providing identity and authentication services.
Basic LDAP Directory and Client Configuration
Figure 17.1. Basic LDAP Directory and Client Configuration

Linux and Unix clients use PAM_LDAP and NSS_LDAP libraries to connect directly to the LDAP services. These libraries allow clients to retrieve user information from the LDAP directory as if the data were stored in /etc/passwd or /etc/shadow. (In real life, the infrastructure may be more complex if a client uses LDAP for identity lookups and Kerberos for authentication or other configurations.)
There are structural differences between an LDAP directory and a FreeIPA server, particularly in schema support and the structure of the directory tree. (For more background on those differences, see Section 1.1, “FreeIPA v. LDAP: A More Focused Type of Service”.) While those differences may impact data (especially with the directory tree, which affects entry names), they have little impact on the client configuration, so it really has little impact on migrating clients to FreeIPA. Recommended Configuration for Fedora Clients

Fedora has a service called the System Security Services Daemon (SSSD). SSSD uses special PAM and NSS libraries (pam_sss and nss_sss, respectively) which allow SSSD to be integrated very closely with FreeIPA and leverage the full authentication and identity featurea in FreeIPA. SSSD has a number of useful features, like caching identity information so that users can log in even if the connection is lost to the central server; these are described in the Fedora Deployment Guide.
Unlike generic LDAP directory services (using pam_ldap and nss_ldap), SSSD establishes relationships between identity and authentication information by defining domains. A domain in SSSD defines four backend functions: authentication, identity lookups, access, and password changes. The SSSD domain is then configured to use an identity provider to supply the information for any one (or all) of those four functions.
SSSD can use FreeIPA for all of its backend functions. This is the ideal configuration because it provides the full range of FreeIPA functionality, unlike generic LDAP identity providers or Kerberos authentication. For example, during daily operation, SSSD enforces host-based access control rules and security features in FreeIPA.


During the migration process from an LDAP directory to FreeIPA, SSSD can seamlessly migrate user passwords without additional user interaction.
Clients and SSSD with a FreeIPA Backend
Figure 17.2. Clients and SSSD with a FreeIPA Backend

The ipa-client-install script automatically configured SSSD to use FreeIPA for all four of its backend services, so Fedora clients are set up with the recommended configuration by default.


This client configuration is only supported for Fedora 15 and later, which supports the latest versions of SSSD and ipa-client. Older versions of Fedora can be configured as described in Section, “Alternative Supported Configuration”. Alternative Supported Configuration

Unix and Linux systems such as Mac, Solaris, HP-UX, AIX, and Scientific Linux support all of the services that FreeIPA manages but do not use SSSD. Likewise, older Fedora versions (6.1 and 5.6) support SSSD but have an older version, which does not support FreeIPA as an identity provider.
When it is not possible to use a modern version of SSSD on a system, then clients can be configured to connect to the FreeIPA server as if it were an LDAP directory service for identity lookups (using nss_ldap) and to FreeIPA as if it were a regular Kerberos KDC (using pam_krb5).
Clients and FreeIPA with LDAP and Kerberos
Figure 17.3. Clients and FreeIPA with LDAP and Kerberos

If a Fedora client is using an older version of SSSD, SSSD can still be configured to use the FreeIPA server as its identity provider and its Kerbero authentication domain; this is described in the SSSD configuration section of the Fedora Deployment Guide.
Any FreeIPA domain client can be configured to use nss_ldap and pam_krb5 to connect to the FreeIPA server. For some maintenance situations and IT structures, a scenario that fits the lowest common denominator may be required, using LDAP for both identity and authentication (nss_ldap and pam_ldap). However, it is generally best practice to use the most secure configuration possible for a client (meaning SSSD and Kerberos or LDAP and Kerberos).

17.1.2. Planning Password Migration

Probably the most visible issue that can impact LDAP-to-FreeIPA migration is migrating user passwords.
FreeIPA (by default) uses Kerberos for authentication and requires that each user have Kerberos hashes stored in the FreeIPA Directory Server in addition to the standard user passwords. To generate these hashes, the user password needs to be available to the FreeIPA server in cleartext. This is the case when the user is created in FreeIPA. However, when the user is migrated from an LDAP directory, the associated user password is already hashed, so the corresponding Kerberos key cannot be generated.


Users cannot authenticate to the FreeIPA domain or access FreeIPA resources until they have Kerberos hashes.
If a user does not have a Kerberos hash[2], that user cannot log into the FreeIPA domain even if he has a user account. There are three options for migrating passwords: forcing a password change, using a web page, and using SSSD.
Migrating users from an existing system provides a smoother transition but also requires parallel management of LDAP directory and FreeIPA during the migration and transition process. If you do not preserve passwords, the migration can be performed more quickly but it requires more manual work by administrators and users.
Resetting Passwords and Forcing a Change
When passwords are changed in FreeIPA, they will be created with the appropriate Kerberos hashes. So one alternative for administrators is to force users to change their passwords by resetting all user passwords when user accounts are migrated. (This can also be done simply by re-creating the LDAP directory accounts in FreeIPA, which automatically creates accounts with the appropriate keys.) The new users are assigned a temporary password which they change at the first login. No passwords are migrated.
Using the Migration Web Page
When it is running in migration mode, FreeIPA has a special web page in its web UI that will capture a cleartext password and create the appropriate Kerberos hash. Administrators could tell users to authenticate once to this web page, which would properly update their user accounts with their password and corresponding Kerberos hash, without requiring password changes.
Using SSSD
SSSD can work with FreeIPA to mitigate the user impact on migrating by generating the required user keys. For deployments with a lot of users or where users shouldn't be burdened with password changes, this is the best scenario.
  1. A user tries to log into a machine with SSSD.
  2. SSSD attempts to perform Kerberos authentication against the FreeIPA server.
  3. Even though the user exists in the system, the authentication will fail with the error key type is not supported because the Kerberos hashes do not yet exist.
  4. SSSD the performs a plaintext LDAP bind over a secure connection.
  5. FreeIPA intercepts this bind request. If the user has a Kerberos principal but no Kerberos hashes, then the FreeIPA identity provider generates the hashes and stores them in the user entry.
  6. If authentication is successful, SSSD disconnects from FreeIPA and tries Kerberos authentication again. This time, the request succeeds because the hash exists in the entry.
That entire process is entirely transparent to the user; as far as users known, they simply log into a client service and it works as normal.

17.1.3. Migration Considerations and Requirements

As you are planning migrating from an LDAP server to FreeIPA, make sure that your LDAP environment is able to work with the FreeIPA migration script. LDAP Servers Supported for Migration

The migration process from an LDAP server to FreeIPA uses a special script, ipa migrate-ds, to perform the migration. This script has certain expectations about the structure of the LDAP directory and LDAP entries in order to work. Migration is supported only for LDAPv3-compliant directory services, which include several common directories:
  • SunONE Directory Server
  • Apache Directory Server
  • OpenLDAP
Migration from an LDAP server to FreeIPA has been tested with 389 Directory Server.


Migration using the migration script is not supported for Microsoft Active Directory because it is not an LDAPv3-compliant directory. Migration Environment Requirements

There are many different possible configuration scenarios for both 389 Directory Server and FreeIPA, and any of those scenarios may affect the migration process. For the example migration procedures in this chapter, these are the assumptions about the environment:
  • A single LDAP directory domain is being migrated to one FreeIPA realm. No consolidation is involved.
  • User passwords are stored as a hash in the LDAP directory that the FreeIPA Directory Server can support.
  • The LDAP directory instance is both the identity store and the authentication method. Client machines are configured to use pam_ldap or nss_ldap to connect to the LDAP server.
  • Entries use only standard LDAP schema. Custom attributes will not be migrated to FreeIPA. Migration Tools

FreeIPA uses a specific command, ipa migrate-ds, to drive the migration process so that LDAP directory data are properly formatted and imported cleanly into the FreeIPA server.
The FreeIPA server must be configured to run in migration mode, and then the migration script can be used. Migration Sequence

There are four major steps when migrating to FreeIPA, but the order varies slightly depending on whether you want to migrate the server first or the clients first.
With a client-based migration, SSSD is used to change the client configuration while a FreeIPA server is configured:
  1. Deploy SSSD.
  2. Reconfigure clients to connect to the current LDAP server and then fail over to FreeIPA.
  3. Install the FreeIPA server.
  4. Migrate the user data using the FreeIPA ipa-migrate-ds script. This exports the data from the LDAP directory, formats for the FreeIPA schema, and then imports it into FreeIPA.
  5. Take the LDAP server offline and allow clients to fail over to FreeIPA transparently.
With a server migration, the LDAP to FreeIPA migration comes first:
  1. Install the FreeIPA server.
  2. Migrate the user data using the FreeIPA ipa-migrate-ds script. This exports the data from the LDAP directory, formats it for the FreeIPA schema, and then imports it into FreeIPA.
  3. Optional. Deploy SSSD.
  4. Reconfigure clients to connect to FreeIPA. It is not possible to simply replace the LDAP server. The FreeIPA directory tree — and therefore user entry DNs — is different than the previous directory tree.
    While it is required that clients be reconfigured, clients do not need to be reconfigured immediately. Updated clients can point to the FreeIPA server while other clients point to the old LDAP directory, allowing a reasonable testing and transition phase after the data are migrated.


    Do not run both an LDAP directory service and the FreeIPA server for very long in parallel. This introduces the risk of user data being inconsistent between the two services.
Both processes provide a general migration procedure, but it may not work in every environment. Set up a test LDAP environment and test the migration process before attempting to migrate the real LDAP environment.

[2] It is possible to use LDAP authentication in FreeIPA instead of Kerberos authentication, which means that Kerberos hashes are not required for users. However, this limits the capabilities of FreeIPA and is not recommended.