Chapter 39. Migrating from an LDAP Directory to IdM
39.1. An Overview of an LDAP to IdM Migration
39.1.1. Planning the Client Configuration
Important
39.1.1.1. Initial Client Configuration (Pre-Migration)

Figure 39.1. Basic LDAP Directory and Client Configuration
/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.)
39.1.1.2. Recommended Configuration for Red Hat Enterprise Linux Clients
pam_sss
and nss_sss
, respectively) which allow SSSD to be integrated very closely with Identity Management and leverage the full authentication and identity features in Identity Management. 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 System-Level Authentication Guide.
pam_ldap
and nss_ldap
), SSSD establishes relationships between identity and authentication information by defining domains. A domain in SSSD defines four back end functions: authentication, identity lookups, access, and password changes. The SSSD domain is then configured to use a provider to supply the information for any one (or all) of those four functions. An identity provider is always required in the domain configuration. The other three providers are optional; if an authentication, access, or password provider is not defined, then the identity provider is used for that function.
Note

Figure 39.2. Clients and SSSD with an IdM Back End
ipa-client-install
script automatically configured SSSD to use IdM for all four of its back end services, so Red Hat Enterprise Linux clients are set up with the recommended configuration by default.
Note
ipa-client
. Older versions of Red Hat Enterprise Linux can be configured as described in Section 39.1.1.3, “Alternative Supported Configuration”.
39.1.1.3. Alternative Supported Configuration
nss_ldap
) and to IdM as if it were a regular Kerberos KDC (using pam_krb5
).

Figure 39.3. Clients and IdM with LDAP and Kerberos
nss_ldap
and pam_krb5
to connect to the IdM 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. This means SSSD or LDAP for identities and Kerberos for authentication.
39.1.2. Planning Password Migration
Important
39.1.2.1. Method 1: Using Temporary Passwords and Requiring a Change
39.1.2.2. Method 2: Using the Migration Web Page
https://ipaserver.example.com/ipa/migration
39.1.2.3. Method 3: Using SSSD (Recommended)
- A user tries to log into a machine with SSSD.
- SSSD attempts to perform Kerberos authentication against the IdM server.
- 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.
- SSSD then performs a plain text LDAP bind over a secure connection.
- IdM intercepts this bind request. If the user has a Kerberos principal but no Kerberos hashes, then the IdM identity provider generates the hashes and stores them in the user entry.
- If authentication is successful, SSSD disconnects from IdM and tries Kerberos authentication again. This time, the request succeeds because the hash exists in the entry.
39.1.2.4. Migrating Cleartext LDAP Passwords
Note
39.1.2.5. Automatically Resetting Passwords That Do Not Meet Requirements
kinit
into the IdM domain.
[jsmith@server ~]$ kinit Password for jsmith@EXAMPLE.COM: Password expired. You must change it now. Enter new password: Enter it again:
39.1.3. Migration Considerations and Requirements
39.1.3.1. LDAP Servers Supported for Migration
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:
- Sun ONE Directory Server
- Apache Directory Server
- OpenLDAP
Note
39.1.3.2. Migration Environment Requirements
- A single LDAP directory domain is being migrated to one IdM realm. No consolidation is involved.
- User passwords are stored as a hash in the LDAP directory. For a list of supported hashes, see the
passwordStorageScheme
attribute in the Password Policy Attributes table in the Red Hat Directory Server 10 Administration Guide. - The LDAP directory instance is both the identity store and the authentication method. Client machines are configured to use
pam_ldap
ornss_ldap
to connect to the LDAP server. - Entries use only the standard LDAP schema. Entries that contain custom object classes or attributes are not migrated to Identity Management.
39.1.3.3. Migration — IdM System Requirements
- 4 cores
- 4GB of RAM
- 30GB of disk space
- A SASL buffer size of 2MB (default for an IdM server)In case of migration errors, increase the buffer size:
[root@ipaserver ~]# ldapmodify -x -D 'cn=directory manager' -w password -h ipaserver.example.com -p 389 dn: cn=config changetype: modify replace: nsslapd-sasl-max-buffer-size nsslapd-sasl-max-buffer-size: 4194304 modifying entry "cn=config"
Set thensslapd-sasl-max-buffer-size
value in bytes.
39.1.3.4. Considerations about Sudo Rules
sudo
with LDAP already, you must manually migrate the sudo
rules stored in LDAP. Red Hat recommends to re-create netgroups in IdM as hostgroups. IdM presents hostgroups automatically as traditional netgroups for sudo
configurations which do not use the SSSD sudo
provider.
39.1.3.5. Migration Tools
ipa migrate-ds
, to drive the migration process so that LDAP directory data are properly formatted and imported cleanly into the IdM server. When using ipa migrate-ds
, the remote system user, specified by the --bind-dn
option, needs to have read access to the userPassword
attribute, otherwise passwords will not be migrated.
39.1.3.6. Improving Migration Performance
- The
nsslapd-cachememsize
attribute, which defines the size allowed for the entry cache. This is a buffer, that is automatically set to 80% of the total cache memory size. For large import operations, this parameter (and possibly the memory cache itself) can be increased to more efficiently handle a large number of entries or entries with larger attributes.For details how to modify the attribute using theldapmodify
, see corresponding section in the Red Hat Directory Server Performance Tuning Guide. - The system
ulimit
configuration option sets the maximum number of allowed processes for a system user. Processing a large database can exceed the limit. If this happens, increase the value:[root@server ~]# ulimit -u 4096
39.1.3.7. Migration Sequence
- Deploy SSSD.
- Reconfigure clients to connect to the current LDAP server and then fail over to IdM.
- Install the IdM server.
- Migrate the user data using the IdM
ipa migrate-ds
script. This exports the data from the LDAP directory, formats for the IdM schema, and then imports it into IdM. - Take the LDAP server offline and allow clients to fail over to Identity Management transparently.
- Install the IdM server.
- Migrate the user data using the IdM
ipa migrate-ds
script. This exports the data from the LDAP directory, formats it for the IdM schema, and then imports it into IdM. - Optional. Deploy SSSD.
- Reconfigure clients to connect to IdM. It is not possible to simply replace the LDAP server. The IdM 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 IdM server while other clients point to the old LDAP directory, allowing a reasonable testing and transition phase after the data are migrated.
Note
Do not run both an LDAP directory service and the IdM server for very long in parallel. This introduces the risk of user data being inconsistent between the two services.