Checklist before cloning an Instance with Digest, SSO, SAML or Multi SSO Integration

Problem

---

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:

• They will receive a logout redirection
• They are forwarded to an external system to authenticate incorrectly
• Their instance local password does not longer works

Cause

---

Due security constrains, most transfers of SAML/SSO or Multi SSO setting will NOT work as they need to be configured on the Identity provider (IdP) as well. They are not universal, so they can't be use 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.

Resolution

---

Before making a clone from one instance to another, please 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.
   
   
   

   Note: 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.

 

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 setup 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 NOTs

• 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.

 

More information is available here:

Clone an instance with a SAML integration