Chapter 4. Migrating from an LDAP directory to IdM If you previously deployed an LDAP server for identity and authentication lookups, you can migrate the lookup service to Identity Management (IdM). IdM offers a migration tool to help you with the following tasks: Transferring user accounts, including passwords and group membership, without losing data. Avoiding expensive configuration updates on the clients. The migration process described here assumes a simple deployment scenario with one namespace in LDAP and one in IdM. For more complex environments, such as those with multiple namespaces or custom schemas, contact the Red Hat support services. 4.1. Considerations in migrating from LDAP to IdM The process of moving from an LDAP server to Identity Management (IdM) has the following stages: Migrating the clients . Plan this stage carefully. Determine which services each client in your current infrastructure uses. These may include for example Kerberos or Systems Security Services Daemon (SSSD). Then determine which of these services you can use in the final IdM deployment. See Planning the client configuration when migrating from LDAP to IdM for more information. Migrating the data . Migrating the passwords . Plan this stage carefully. IdM requires Kerberos hashes for every user account in addition to passwords. Some of the considerations and migration paths for passwords are covered in Planning password migration when migrating from LDAP to IdM . You can first migrate the server part and then the clients or first the clients and then the server. For more information about the two types of migration, see LDAP to IdM migration sequence . Important It is strongly recommended that you set up a test LDAP environment and test the migration process before attempting to migrate the real LDAP environment. When testing the environment, do the following: Create a test user in IdM and compare the output of migrated users to that of the test user. Ensure that the migrated users contain the minimal set of attributes and object classes present on the test user. Compare the output of migrated users, as seen on IdM, to the source users, as seen on the original LDAP server. Ensure that imported attributes are not copied twice and that they have the correct values. 4.2. Planning the client configuration when migrating from LDAP to IdM Identity Management (IdM) 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 and your IT maintenance priorities. Consider also the client's functional area: a development machine typically requires a different configuration than production servers or user laptops do. Important Most environments have a mixture of different ways in which clients connect to the IdM domain. Administrators must decide which scenario is best for each individual client. 4.2.1. Initial, pre-migration client configuration 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. An Identity Management (IdM) server differs from an LDAP directory, 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. 4.2.2. Recommended configuration for RHEL clients Note The client configuration described is only supported for RHEL 6.1 and later and RHEL 5.7 later, which support the latest versions of SSSD and the ipa-client package. Older versions of RHEL can be configured as described in Alternative supported configuration . 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: Authentication Identity lookups Access Password changes 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. Additional information Understanding SSSD and its benefits 4.2.3. Alternative supported configuration 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: The client connects to the IdM server as if it were an LDAP directory server for identity lookups, by using nss_ldap . The client connects to the IdM server as if it were a regular Kerberos KDC, by using pam_krb5 . 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. 4.3. Planning password migration when migrating from LDAP to IdM A crucial question to answer before migrating users from LDAP to Identity Management (IdM) is whether to migrate user passwords or not. The following options are available: Migrating users without passwords Can be performed more quickly but requires more manual work by administrators and users. In certain situations, this is the only available option: for example, if the original LDAP environment stored cleartext user passwords or if the passwords do not meet the password policy requirements defined in IdM . When migrating user accounts without passwords, you reset all user passwords. The migrated users are assigned a temporary password that they change at the first login. For more information about how to reset passwords, see Changing and resetting user passwords in HREL 7 IdM documentation. Migrating users with their passwords Provides a smoother transition but also requires parallel management of LDAP directory and IdM during the migration and transition process. The reason for this is that by default, IdM uses Kerberos for authentication and requires that each user has a Kerberos hash stored in the IdM Directory Server in addition to the standard user password. To generate the hash, the user password needs to be available to the IdM server in clear text. When you create a new user password, the password is available in clear text before it is hashed and stored in IdM. 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. Important By default, users cannot authenticate to the IdM domain or access IdM resources until they have Kerberos hashes - even if the user accounts already exist. One workaround is available: using LDAP authentication in IdM instead of Kerberos authentication. With this workaround, Kerberos hashes are not required for users. However, this workaround limits the capabilities of IdM and is not recommended. The following sections explain how to migrate users and their passwords: Methods for migrating passwords when migrating LDAP to IdM Using a web page Using SSSD Planning the migration of cleartext LDAP passwords Planning the migration of LDAP passwords that do not meet the IdM requirements 4.3.1. Methods for migrating passwords when migrating LDAP to IdM 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. Workflow 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 fails with the error key type is not supported because the Kerberos hashes do not exist yet. SSSD 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. 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. 4.3.2. Planning the migration of cleartext LDAP passwords 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 login. For more information, see Planning the migration of LDAP passwords that do not meet the IdM requirements . 4.3.3. 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: 4.4. Further migration considerations and requirements As you are planning a migration from an LDAP server to Identity Management (IdM), ensure that your LDAP environment is able to work with the IdM migration script. 4.4.1. LDAP servers supported for migration 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: Sun ONE Directory Server Apache Directory Server OpenLDAP Migration from an LDAP server to IdM has been tested with Red Hat Directory Server and OpenLDAP. Note Migration using the migration script is not supported for Microsoft Active Directory because it is not an LDAPv3-compliant directory. For assistance with migrating from Active Directory, contact Red Hat Professional Services. 4.4.2. LDAP environment requirements for migration 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: A single LDAP directory domain is being migrated to one IdM realm. No consolidation is involved. A user password is stored as a hash in the LDAP directory. For a list of supported hashes, see the Password Storage Schemes section in the Configuration, Command, and File Reference title available in the Red Hat Directory Server 10 section of Red Hat Directory Server Documentation . The LDAP directory instance is both the identity store and the authentication method. Client machines are configured to use the pam_ldap or nss_ldap library 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 IdM. The migrate-ds command only migrates the following accounts: Those containing a gidNumber attribute. The attribute is required by the posixAccount object class. Those containing an sn attribute. The attribute is required by the person object class. 4.4.3. IdM system requirements for migration 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: 4 cores 4GB of RAM 30GB of disk space A SASL buffer size of 2MB, which is the default for an IdM server In case of migration errors, increase the buffer size: Set the nsslapd-sasl-max-buffer-size value in bytes. Additional resources IdM server hardware recommendations 4.4.4. User and group ID numbers 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: You know your LDAP ID range. You know your IdM ID range. No overlap exists between UIDs and GIDs on the LDAP server and existing UIDs or GIDs on the RHEL system or IdM deployment. The migrated LDAP UIDs and GIDs fit into the IdM ID range. If needed, create a new IdM ID range prior to migration. Additional resources Adding a new IdM ID range 4.4.5. Considerations about sudo rules 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. 4.4.6. LDAP to IdM migration tools 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 . 4.4.7. Improving LDAP to IdM migration performance 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: 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, you can increase this parameter and possibly the memory cache itself. This increase will improve the efficiency of the directory service in handling a large number of entries or entries with large attributes. For details on how to modify the attribute using the dsconf command, see Adjusting the entry cache size . 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: Additional resources Adjusting IdM Directory Server performance 4.4.8. LDAP to IdM migration sequence 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 . Important Both the client-first and server-first migrations provide a general migration procedure, but they 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. Client-first migration SSSD is used to change the client configuration while an Identity Management (IdM) server is configured: 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 IdM transparently. Server-first migration The LDAP to IdM migration comes first: 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 from the directory tree. While it is required that clients must 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 becoming inconsistent between the two services. 4.5. Customizing the migration from LDAP to IdM You can migrate your authentication and authorization services from an LDAP server to Identity Management (IdM) using the ipa migrate-ds command. Without additional options, the command takes the LDAP URL of the directory to migrate and exports the data based on common default settings. You can customize the migration process and how data is identified and exported by using different ipa migrate-ds command options. Customize the migration if your LDAP directory tree has a unique structure or if you know you must exclude certain entries or attributes within entries. 4.5.1. Examples of customizing the Bind DN and Base DN during the migration from LDAP to IdM 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: Customizing the Bind DN By default, the DN " cn=Directory Manager " is used to bind to the remote LDAP directory. Use the --bind-dn option to specify a custom bind DN: Customizing the naming context If the LDAP server naming context differs from the one used in IdM, the base DNs for objects are transformed. For example: uid= user ,ou=people,dc=ldap,dc=example,dc=com is migrated to uid= user ,ou=people,dc=idm,dc=example,dc=com . Using the --base-dn option, you can change the target for container subtrees and thus set the base DN used on the remote LDAP server for the migration: Additional resources ipa migrate-ds --help 4.5.2. The migration of specific subtrees 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: --user-container --group-container Note In both cases, the subtree must be a relative distinguished name (RDN) and must be relative to the base DN. For example, you can migrate the >ou=Employees,dc=example,dc=com directory tree by using --user-container=ou=Employees . For example: Optionally, add the --scope option to the ipa migrate-ds command to set the scope: onelevel : Default. Only entries in the specified container are migrated. subtree : Entries in the specified container and all subcontainers are migrated. base : Only the specified object itself is migrated. 4.5.3. The inclusion and exclusion of entries 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: 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: 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: 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: 4.5.4. The exclusion of entry attributes 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: --user-ignore-objectclass --user-ignore-attribute --group-ignore-objectclass --group-ignore-attribute For example, to exclude the userCertificate attribute and strongAuthenticationUser object class for users and the groupOfCertificates object class for groups: Note Make sure not to ignore any required attributes. Also, when excluding object classes, make sure to exclude any attributes that only that object class supports. Additional resources LDAP environment requirements for migration 4.5.5. The schema to use when migrating from LDAP to IdM and the schema compat feature 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: 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. 4.6. Migrating an LDAP server to IdM You can migrate your authentication and authorization services from an LDAP server to Identity Management (IdM) using the ipa migrate-ds command. Warning This is a general migration procedure that may not work in every environment. It is strongly recommended that you set up a test LDAP environment and test the migration process before attempting to migrate the real LDAP environment. When testing the environment, do the following: Create a test user in IdM and compare the output of migrated users to that of the test user. Compare the output of migrated users, as seen on IdM, to the source users, as seen on the original LDAP server. For more guidance, see the Verification section below. Prerequisites You have administrator privileges to the LDAP directory. If IdM is already installed, you have administrator privileges to IdM. You are logged in as root on the RHEL system on which you are executing the procedure below. You have read and understood the following chapters: Considerations in migrating from LDAP to IdM . Planning the client configuration when migrating from LDAP to IdM . Planning password migration when migrating from LDAP to IdM . Further migration considerations and requirements . Customizing the migration from LDAP to IdM . Procedure If IdM is not yet installed: install the IdM server, including any custom LDAP directory schema, on a different machine from the one on which the existing LDAP directory is installed. For details, see Installing Identity Management . Note Custom user or group schemas have limited support in IdM. They can cause problems during the migration because of incompatible object definitions. For performance reasons, disable the compat plug-in: For more information about the schema compat feature and the benefits of disabling it for the migration, see The schema to use when migrating from LDAP to IdM and the schema compat feature . Restart the IdM Directory Server instance: Configure the IdM server to allow migration: By setting --enable-migration to TRUE, you do the following: Allow pre-hashed passwords during an LDAP add operation. Configure SSSD to try the password migration sequence if the initial Kerberos authentication fails. For more information, see the Workflow section in Using SSSD when migrating passwords from LDAP to IdM . Run the IdM migration script, ipa migrate-ds , with the options that are relevant for your use case. For more information, see Customizing the migration from LDAP to IdM . Note If you did not disable the compat plug-in in one of the steps, add the --with-compat option to ipa migrate-ds : Re-enable the compat plug-in: Restart the IdM Directory Server: When all users have had their passwords migrated, disable the migration mode: Optional: When all of the users have been migrated, reconfigure non-SSSD clients to use Kerberos authentication, that is pam_krb5 , instead of LDAP authentication, that is pam_ldap . For more information, see Configuring a Kerberos Client in the RHEL 7 System-level Authentication Guide . Have users generate their hashed Kerberos passwords. Choose one of the methods described in Planning password migration when migrating from LDAP to IdM . If you decide on the SSSD method : Move clients that have SSSD installed from the LDAP directory to the IdM directory, and enroll them as clients with IdM. This downloads the required keys and certificates. On Red Hat Enterprise Linux clients, this can be done using the ipa-client-install command. For example: If you decide on the IdM migration web page method: Instruct users to log into IdM using the migration web page: To monitor the user migration process, query the existing LDAP directory to see which user accounts have a password but do not yet have a Kerberos principal key. Note Include the single quotes around the filter so that it is not interpreted by the shell. When the migration of all clients and users is complete, decommission the LDAP directory. Verification Create a test user in IdM by using the ipa user-add command. Compare the output of migrated users to that of the test user. Ensure that the migrated users contain the minimal set of attributes and object classes present on the test user. For example: Compare the output of migrated users, as seen on IdM, to the source users, as seen on the original LDAP server. Ensure that imported attributes are not copied twice and that they have the correct values. Additional resources Migrating from LDAP to IdM over SSL 4.7. Migrating from LDAP to IdM over SSL You can migrate your authentication and authorization services from an LDAP server to Identity Management (IdM) using the ipa migrate-ds command. Follow this procedure to encrypt the data transmitted during the migration. Warning This is a general migration procedure that may not work in every environment. It is strongly recommended that you set up a test LDAP environment and test the migration process before attempting to migrate the real LDAP environment. When testing the environment, do the following: Create a test user in IdM and compare the output of migrated users to that of the test user. Compare the output of migrated users, as seen on IdM, to the source users, as seen on the original LDAP server. For more guidance, see the Verification section below. Prerequisites You have administrator privileges to the LDAP directory. If IdM is already installed, you have administrator privileges to IdM. You are logged in as root on the RHEL system on which you are executing the procedure below. You have read and understood the following chapters: Considerations in migrating from LDAP to IdM . Planning the client configuration when migrating from LDAP to IdM . Planning password migration when migrating from LDAP to IdM . Further migration considerations and requirements . Customizing the migration from LDAP to IdM . Procedure Store the certificate of the CA that issued the remote LDAP server certificate in a file on the future IdM server. For example: /tmp/remote.crt . Follow the steps described in Migrating an LDAP server to IdM . However, for an encrypted LDAP connection during the migration, use the ldaps protocol in the URL and pass the --ca-cert-file option to the ipa migrate-ds command. For example: Verification Create a test user in IdM by using the ipa user-add command. Compare the output of migrated users to that of the test user. Ensure that the migrated users contain the minimal set of attributes and object classes present on the test user. For example: Compare the output of migrated users, as seen on IdM, to the source users, as seen on the original LDAP server. Ensure that imported attributes are not copied twice and that they have the correct values.

Commands:
[migrated_idm_user@idmclient ~]USD kinit Password for migrated_idm_user@IDM.EXAMPLE.COM: Password expired. You must change it now. Enter new password: Enter it again:
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"
ulimit -u 4096
ipa migrate-ds ldap://ldap.example.com:389
ipa migrate-ds ldap://ldap.example.com:389 --bind-dn=cn=Manager,dc=example,dc=com
ipa migrate-ds --base-dn="ou=people,dc=example,dc=com" ldap://ldap.example.com:389
ipa migrate-ds --user-container=ou=employees --group-container="ou=employee groups" ldap://ldap.example.com:389
ipa migrate-ds --user-objectclass=fullTimeEmployee ldap://ldap.example.com:389
ipa migrate-ds --group-objectclass=groupOfNames --group-objectclass=groupOfUniqueNames ldap://ldap.example.com:389
ipa migrate-ds --exclude-groups="Golfers Group" --exclude-users=idmuser101 --exclude-users=idmuser102 ldap://ldap.example.com:389
ipa migrate-ds --user-objectclass=fullTimeEmployee --exclude-users=jsmith --exclude-users=bjensen --exclude-users=mreynolds ldap://ldap.example.com:389
ipa migrate-ds --user-ignore-attribute=userCertificate --user-ignore-objectclass=strongAuthenticationUser --group-ignore-objectclass=groupOfCertificates ldap://ldap.example.com:389
ipa migrate-ds --schema=RFC2307 ldap://ldap.example.com:389
ipa-compat-manage disable
systemctl restart dirsrv.target
ipa config-mod --enable-migration=TRUE
ipa migrate-ds --your-options ldap://ldap.example.com:389
ipa migrate-ds --your-options --with-compat ldap://ldap.example.com:389
ipa-compat-manage enable
systemctl restart dirsrv.target
ipa config-mod --enable-migration=FALSE
ipa-client-install --enable-dns-update
https://ipaserver.example.com/ipa/migration
ldapsearch -LL -x -D 'cn=Directory Manager' -w secret -b 'cn=users,cn=accounts,dc=example,dc=com' '(&(!(krbprincipalkey= ))(userpassword= ))' uid
ipa user-show --all testing_user dn: uid=testing_user,cn=users,cn=accounts,dc=idm,dc=example,dc=com User login: testing_user First name: testing Last name: user Full name: testing user Display name: testing user Initials: tu Home directory: /home/testing_user GECOS: testing user Login shell: /bin/sh Principal name: testing_user@IDM.EXAMPLE.COM Principal alias: testing_user@IDM.EXAMPLE.COM Email address: testing_user@idm.example.com UID: 1689700012 GID: 1689700012 Account disabled: False Preserved user: False Password: False Member of groups: ipausers Kerberos keys available: False ipauniqueid: 843b1ac8-6e38-11ec-8dfe-5254005aad3e mepmanagedentry: cn=testing_user,cn=groups,cn=accounts,dc=idm,dc=example,dc=com objectclass: top, person, organizationalperson, inetorgperson, inetuser, posixaccount, krbprincipalaux, krbticketpolicyaux, ipaobject, ipasshuser, ipaSshGroupOfPubKeys, mepOriginEntry
ipa migrate-ds --ca-cert-file= /tmp/remote.crt --your-other-options ldaps:// ldap.example.com :636
ipa user-show --all testing_user dn: uid=testing_user,cn=users,cn=accounts,dc=idm,dc=example,dc=com User login: testing_user First name: testing Last name: user Full name: testing user Display name: testing user Initials: tu Home directory: /home/testing_user GECOS: testing user Login shell: /bin/sh Principal name: testing_user@IDM.EXAMPLE.COM Principal alias: testing_user@IDM.EXAMPLE.COM Email address: testing_user@idm.example.com UID: 1689700012 GID: 1689700012 Account disabled: False Preserved user: False Password: False Member of groups: ipausers Kerberos keys available: False ipauniqueid: 843b1ac8-6e38-11ec-8dfe-5254005aad3e mepmanagedentry: cn=testing_user,cn=groups,cn=accounts,dc=idm,dc=example,dc=com objectclass: top, person, organizationalperson, inetorgperson, inetuser, posixaccount, krbprincipalaux, krbticketpolicyaux, ipaobject, ipasshuser, ipaSshGroupOfPubKeys, mepOriginEntry