Date: Thu, 28 Mar 2024 13:03:55 +0000 (UTC) Message-ID: <1019819783.53.1711631035948@d5b512ddcb69> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_52_1253453909.1711631035948" ------=_Part_52_1253453909.1711631035948 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
Organizations with multiple Orgs= can migrate Accounts from one Org to another. There are several ways to mi= grate Accounts:
Both Project options allow you t= o migrate all accounts. To migrate individual Accounts, select them in the = Assets table and copy them.
It is possible for different Org= s owned by the same organization to use different types of Account = encryption. Because of the security risk, SnapLogic does not suppo= rt the migration of accounts from Orgs with Enhanced Encryption to Orgs usi= ng standard account encryption. In this situation, you must manually recrea= te the accounts in the target Org.
When you Migrate Accou= nts from one Org to another, consider the following:
If your org is configured=
for Enhanced Account Encryption, the SnapLogic Create Snap and the SnapLogic =
Update Snap enable you to create/update accounts when the sensitiv=
e fields are provided in plain text. The Snaps will encrypt the data automa=
tically.
The presence of 'key' in the property = tells the Snap that the field is already encrypted. Therefore, when the pro= perty value is in plain text, make sure you delete the 'key' field in the s= ensitive property object. Otherwise, the Snap cannot encrypt the field.&nbs= p;
keytool
command e=
ither in a single step or multiple steps. Once the keys are added, the=
Snaplexes on the destination org can be restarted from the dashboard. =
;The restarted JCCs will pick up the added source keys and use them du=
ring migration for account re-encryption.
Make a backup of both source and destination keystores before proce= eding with adding the keys to the destination keystores.
keyt= ool -importkeystore -srckeystore jcc-datakeys.jks -srcstoretype JCEKS -srcstorepass `cat jcc-datakeys.pass` -srcalias 'account-autogen' -destkeystore <destination-machine>:= <keystore-location>/jcc-datakeys.jks -deststoretype JCEKS -deststorepass <destination-machine>:<keystore-location>/jccdat= akeys.pass -destalias source-account-autogen
Export the source key to a temporary keysto= re.
keyt= ool -importkeystore -srckeystore jcc-datakeys.jks -destkeystore jcc-datakeys-src-copy.jks -srcstoretype JCEKS -deststoretype JCEKS -srcstor= epass `cat jcc-datakeys.pass` -deststorepass changeit -srcalias account-autogen -= destalias source-account-autogen -srckeypass `cat jcc-datakeys.pass` -destkeypass changeit
account-au=
togen
. So while importing the source key to destination, a new name =
should be chosen for source key-alias. A recommended name would have source=
org name followed by account-autogen
. For example, SnaplogicDev-account-autogen
.changeit
.Go to the keystore in the destination JCCs.= Import (add) the source key to the destination key using the following com= mand:
keyt= ool -importkeystore -srckeystore jcc-datakeys-src-copy.jks -destkeystore jcc-datakeys.jks -srcstoretype JCEKS -deststoretype JCEKS -sr= cstorepass changeit -srckeypass changeit -deststorepass `cat jcc-datak= eys.pass` -srcalias source-account-autogen -destalias source-account-autogen
Change the source key password to use the k= eystore password.
keyt= ool -keypasswd -alias source-account-autogen -keypass changeit -new `cat jcc-datakeys.pass`
Once the keys are added, you can list the k=
eys to confirm that the source key is added with alias source-ac=
count-autogen
keyt= ool -list -keystore jcc-datakeys.jks -storetype JCEKS -storepass `cat jcc-datakeys.pass`