Customer's can sometimes encounter difficulties when attempting to request a clone if the target instance has an SSO solution or LDAP integration enabled.
This article will explain the cause of some of these problems as well as a solution to ensure a successful clone.
This article is for the specific case in which the user account used to authenticate to the target instance for the clone is receiving an error indicating the account cannot authenticate, despite the fact that the credentials used are valid login credentials for that target instance.
Note that in many cases, a Clone Target can successfully be created using those credentials, however, when attempting to create the actual clone request, a message appears indicating that the User name or password is incorrect. The usual cause of this issue is that the account being used for authentication of the clone request is an account configured on the target instance to use SSO login credentials. However, because the current cloning system is unable to pass along the necessary additional information with those credentials, when attempting to submit the actual clone request, authentication fails and the clone request cannot be successfully submitted.
One of the most common methods to fix this is to create a dedicated user account (which is not linked to SSO or LDAP) on the target instance, and then create the clone request using this new account.
Thus, the first step is to create a new, dedicated account on the target instance. Since this account (and it's corresponding password and authentication information) must be created on the target instance, it will be overwritten upon completion of the clone so this account is, in effect, a one use account.
The account should be provided a Name and User ID that is descriptive of it's purpose (i.e. clone_admin). Ensure the account is not locked out and is set as active. Also ensure that none of the information to link the account to LDAP or SSO is configured, as this should be a stand-alone account that is not associated with the LDAP or SSO system in any way. Also, the password used in this password field will be needed when creating the clone request which will use this account. However, for optimal security this password should not be written down or used in any other location or passed to any individuals or processes that will not be part of this clone process. It should also be noted that as this account is created on the target instance, and usually this user account will not be preserved during the clone, this password and account will not be a potential vulnerability for the target instance once the clone has completed as the account will no longer exist upon that clone completion.
After the account has been created, the account should be associated to either or both the admin and the clone_admin user roles.
After the account has been successfully created and added to the appropriate groups, the clone request can then be created on the source instance, using this new account at the dialog box that appears requesting credentials for the target instance.
Note that, in order to prevent having to recreate this account each time the target is cloned over, this account could be created on the source instance and ensured to not be excluded during the clone process,. Alternatively, a data preserver could be created on the source instance to ensure that this account is not overwritten during the clone procedure. In either of those cases, the password should be randomized or scrambled after the clone request has completed, so as to ensure this account is not a potential access point for unauthorized users of the system.
For general information on requesting a clone record, see the following articles: