Before deciding on the specifics of the client configuration in Identity Management (IdM), first establish the specifics of the current, pre-migration configuration.

The initial state for almost all LDAP deployments that are to be migrated is that there is an LDAP service providing identity and authentication services.

Figure 4.1. Basic LDAP directory and client configuration

Linux and Unix clients use the 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 an Identity Management (IdM) server, particularly in schema support and the structure of the directory tree. For more background on those differences, see the Contrasting IdM with a Standard LDAP Directory section from the Planning the client configuration when migrating from LDAP to IdM. Those differences may impact data, especially with the directory tree, which affects entry names. However, the differences have little impact on the client configuration and on migrating clients to IdM.

The System Security Services Daemon (SSSD) in Red Hat Enterprise Linux (RHEL) uses special PAM and NSS libraries, pam_sss and nss_sss. Using these libraries, SSSD can integrate very closely with Identity Management (IdM) and benefit from its full authentication and identity features. SSSD has a number of useful features, such as caching identity information so that users can log in even if the connection to the central server is lost.

Unlike generic LDAP directory services that use the pam_ldap and nss_ldap libraries, SSSD establishes relationships between identity and authentication information by defining domains. A domain in SSSD defines the following back end functions:

The SSSD domain is then configured to use a provider to supply the information for any one, or all, of these functions. The domain configuration always requires an identity provider. 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.

SSSD can use IdM for all of its back end functions. This is the ideal configuration because it provides the full range of IdM 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 IdM.

Figure 4.2. Clients and SSSD with an IdM back end

The ipa-client-install script automatically configures SSSD to use IdM for all its back end services, so that RHEL clients are set up with the recommended configuration by default.

Unix and Linux systems such as Mac, Solaris, HP-UX, AIX, and Scientific Linux support all of the services that Identity Management (IdM) manages but do not use SSSD. Similarly, older Red Hat Enterprise Linux (RHEL) versions, specifically 6.1 and 5.6, support SSSD but have an older version, which does not support IdM as an identity provider.

If it is not possible to use a modern version of SSSD on a system, then clients can be configured in the following way:

For more information about configuring a RHEL client with an older version of SSSD to use the IdM server as its identity provider and its Kerberos authentication domain, see the Configuring identity and authentication providers for SSSD section of the RHEL 7 System-Level Authentication Guide.

Figure 4.3. Clients and IdM with LDAP and Kerberos

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. However, for some maintenance situations and IT structures, you may need to resort to the simplest possible scenario: configuring LDAP to provide both identity and authentication by using the nss_ldap and pam_ldap libraries on the clients.

To migrate user accounts from LDAP to Identity Management (IdM) without forcing the users to change their passwords, you can use the following methods:

Method 1: Using the migration web page

Tell users to enter their LDAP credentials once into a special page in the IdM Web UI, https://ipaserver.example.com/ipa/migration. A script running in the background then captures the clear text password and properly updates the user account with the password and an appropriate Kerberos hash.

Method 2 (recommended): Using SSSD

Mitigate the user impact of the migration by using the System Security Services Daemon (SSSD) to generate the required user keys. For deployments with a lot of users or where users should not be burdened with password changes, this is the best scenario.

With method 2, the entire process is invisible to the users. They log in to a client service without noticing that their password has been moved from LDAP to IdM.

Although in most deployments LDAP passwords are stored encrypted, there may be some users or some environments that use cleartext passwords for user entries.

When users are migrated from the LDAP server to the IdM server, their cleartext passwords are not migrated over because IdM does not allow cleartext passwords. Instead, a Kerberos principal is created for each user, the keytab is set to true, and the password is set as expired. This means that IdM requires the user to reset the password at the next login. For more information, see Planning the migration of LDAP passwords that do not meet the IdM requirements.

If user passwords in the original directory do not meet the password policies defined in Identity Management (IdM), the passwords become invalid after the migration.

Password reset is done automatically the first time a user attempts to obtain a Kerberos ticket-granting ticket (TGT) in the IdM domain by entering kinit. The user is forced to change his or her password:

[migrated_idm_user@idmclient ~]$ kinit
Password for migrated_idm_user@IDM.EXAMPLE.COM:
Password expired.  You must change it now.
Enter new password:
Enter it again:

The migration process from an LDAP server to IdM uses a special script, ipa migrate-ds, to perform the migration. This script has specific requirements regarding the structure of the LDAP directory and LDAP entries. Migration is supported only for LDAPv3-compliant directory services, which include several common directories:

Migration from an LDAP server to IdM has been tested with Red Hat Directory Server and OpenLDAP.

Many different possible configuration scenarios exist for LDAP servers and for Identity Management (IdM), which affects the smoothness of the migration process. For the example migration procedures, these are the assumptions about the environment:

With a moderately-sized directory of around 10,000 users and 10 groups, it is necessary to have a powerful enough target IdM system to allow the migration to proceed. The minimum requirements for a migration are:

When migrating from LDAP to an IdM deployment, ensure that no user ID (UID) and group ID (GID) conflict exists between the deployments. Before migration, verify that:

If you are using sudo with LDAP, you must migrate the sudo rules stored in LDAP to Identity Management (IdM) manually. Red Hat recommends that you recreate netgroups in IdM as hostgroups. IdM presents hostgroups automatically as traditional netgroups for sudo configurations that do not use the SSSD sudo provider.

Identity Management (IdM) uses a specific command, ipa migrate-ds, to execute 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, must have read access to the userPassword attribute, otherwise passwords will not be migrated.

The IdM server must be configured to run in migration mode, and then the migration script can be used. For details, see Migrating an LDAP server to IdM.

An LDAP migration is essentially a specialized import operation for the 389 Directory Server (DS) instance within the IdM server. Tuning the 389 DS instance for better import operation performance can help improve the overall migration performance.

There are two parameters that directly affect import performance:

There are four major steps when migrating to IdM, but their order varies depending on whether you want to first migrate the server or the clients.

Use the ipa migrate-ds command to migrate from LDAP to Identity Management (IdM). Without additional options, the command takes the LDAP URL of the directory to migrate and exports the data based on common default settings. The following are examples of modifying the default settings:

# ipa migrate-ds ldap://ldap.example.com:389

The default directory structure places person entries in the ou=People subtree and group entries in the ou=Groups subtree. These subtrees are container entries for those different types of directory data. If you do not use any options with the migrate-ds command, then the utility assumes that the given LDAP directory uses the ou=People and ou=Groups structure.

Many deployments may have an entirely different directory structure or you may only want to export certain parts of the original directory tree. As an administrator, you can use the following options to specify the RDN of a different user or group subtree on the source LDAP server:

For example:

[ipaserver ~]# ipa migrate-ds --user-container=ou=employees \
--group-container="ou=employee groups" ldap://ldap.example.com:389

Optionally, add the --scope option to the ipa migrate-ds command to set the scope:

By default, the ipa migrate-ds script imports every user entry with the person object class and every group entry with the groupOfUniqueNames or groupOfNames object class.

In some migration paths, only specific types of users and groups may need to be exported, or, alternatively, specific users and groups may need to be excluded. You can select which types of users and groups to include by setting which object classes to search for when looking for user or group entries.

This option is particularly useful when you use custom object classes for different user types. For example, the following command migrates only users with the custom fullTimeEmployee object class:

[root@ipaserver ~]# ipa migrate-ds --user-objectclass=fullTimeEmployee ldap://ldap.example.com:389

Because of the different types of groups, this is also very useful for migrating only certain types of groups, such as user groups, while excluding other types of groups, like certificate groups. For example:

[root@ipaserver ~]# ipa migrate-ds --group-objectclass=groupOfNames --group-objectclass=groupOfUniqueNames ldap://ldap.example.com:389

Specifying user and group entries to migrate based on object class implicitly excludes all other users and groups from migration.

Alternatively, it can be useful to migrate all user and group entries except for just a small handful of entries. You can exclude specific user or group accounts while migrating all others of that type. For example, this excludes only a hobbies group and two users:

[root@ipaserver ~]# ipa migrate-ds --exclude-groups="Golfers Group" --exclude-users=idmuser101 --exclude-users=idmuser102 ldap://ldap.example.com:389

Exclude statements are applied to users matching the pattern in the uid and to groups matching it in the cn attribute.

You can migrate a general object class but exclude specific entries of that class. For example, this specifically includes users with the fullTimeEmployee object class, yet excludes three managers:

[root@ipaserver ~]# ipa migrate-ds --user-objectclass=fullTimeEmployee --exclude-users=jsmith --exclude-users=bjensen --exclude-users=mreynolds ldap://ldap.example.com:389

By default, every attribute and object class for a user or group entry is migrated. In certain scenarios, that may not be realistic, either because of bandwidth and network constraints or because the attribute data are no longer relevant. For example, if users are going to be assigned new user certificates as they join the Identity Management (IdM) domain, then migrating the userCertificate attribute would be useless.

You can ignore specific object classes and attributes by using the following options with the migrate-ds command:

For example, to exclude the userCertificate attribute and strongAuthenticationUser object class for users and the groupOfCertificates object class for groups:

[root@ipaserver ~]# ipa migrate-ds --user-ignore-attribute=userCertificate --user-ignore-objectclass=strongAuthenticationUser --group-ignore-objectclass=groupOfCertificates ldap://ldap.example.com:389

Identity Management (IdM) uses the RFC2307bis schema to define user, host, host group, and other network identities. However, if the LDAP server used as the source for the migration uses the RFC2307 schema instead, specify the --schema option with the ipa migrate-ds command:

[root@ipaserver ~]# ipa migrate-ds --schema=RFC2307 ldap://ldap.example.com:389

Alternatively, IdM has a built-in schema compat feature that allows IdM to reformat data for systems that do not support RFC2307bis. The compat plugin is enabled by default, which means that the directory server computes an alternate view of the users and groups and provides this view in the cn=users,cn=compat,dc=example,dc=com container entry. It does this by precomputing the contents of its entries at startup-time and refreshing its entries as needed.

It is recommended that this feature is disabled during the migration to reduce system overhead.