Checklist before cloning an instance with Digest / SSO / SAML / Multi SSO Integration to prevent denied authentication on clone targetIssue 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 redirectionbeing forwarded to an external system to authenticate incorrectlytheir instance local password no longer workingCauseDue 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.ResolutionBefore making a clone from one instance to another, ensure the followings: 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.communicationscom.snc.integration.saml_esig 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.Preserve SAML users on sys_user related to SAML/SSO/Multi SSO. Use the System Clone > Preserve Data on the source instance.Exclude the Multi SSO tables sso_properties, digest_properties and saml2_update1_properties.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. Warning: Out the box data preserver (clone_data_preserver) "Core Instance Properties" exclude some SAML/SSO/Multi SSO data on sys_properties 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. Related LinksData 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)