Cloning could cause your target instance to be inaccessible if it is done incorrectly and the source or target instance has SAML setup. We do not recommend to copy the SAML configuration from one system into another.

Symptoms

After a clone, some users will not be able to login into their instance. They could experience either:

• denied log in with "Username or password not valid"
• receiving a logout redirection
• being forwarded to an external system to authenticate incorrectly
• their instance local password no longer working

Due to security constraints, most transfers of SAML/SSO or Multi SSO settings will not work as they need to be configured on the Identity Provider (IdP) as well. They are not universal, so they can not be used on multiple systems. Instead, each instance needs to be registered on the final IdP independently.

If you create or overwrite a working setup, it could cause the target instance to fail to authenticate.

Before making a clone from one instance to another, ensure the followings:

1. Preserve SAML properties on sys_properties related to SAML/SSO/Multi SSO. Use the System Clone > Preserve Data on the source instance. If you need them, export them into XML, then manually import them on the target. As a guide, preserve properties starting with:
   • glide.authenticate.
   • glide.security.
   • glide.entry.
   • glide.script.
   • glide.session.
   • glide.saml2.
   • com.glide.communications
   • com.snc.integration.saml_esig
2. Preserve SAML certificates on sys_certificate related to SAML/SSO/Multi SSO. Use the System Clone > Preserve Data on the source instance. If you need them, export them into XML, then manually import them on the target.
3. Preserve SAML users on sys_user related to SAML/SSO/Multi SSO. Use the System Clone > Preserve Data on the source instance.
4. Exclude the Multi SSO tables sso_properties, digest_properties and saml2_update1_properties.
5. Ensure you have a LOCAL admin account on sys_user (not in LDAP or SAML) record on the target clone manually created and with a sys_id that does not exist on the source instance of the clone.

Finally,
DO

• Manually create the SAML/SSO/Multi SSO records on each instance independently as they need to be set up on their IdP as well independently.
• If you need to copy some setup information (e.g. sys_properties records), export the records into XML, then on the target import them as XML accordingly or as part of your Update sets.

DO NOT

• Do not try to clone the SAML/SSO/Multi SSO setup from one system to another.
• Do not change the sys_id of your Multi SSO provider record as it will force your users to flush their cookies.

Reset the MFA on a cloned instance

This video shows how to reset the MFA on a cloned instance. 

Data preservation on cloning target instances

Clone an instance with a SAML integration

Users not able  to login in cloned target instance using Multi Factor Authentication (MFA)