Guide to installing and configuring Salesforce Identity Connect.

1. Download and unzip Identity Connect 7.1.

2. Stop the Identity Connect 3 instance:

   -> shutdown

   path/to/salesforceIdConnect-3/shutdown.sh

   Note

   On Windows systems, stop the OpenIDM application in the Windows Task Manager, stop the Windows service, or type shutdown in the Felix console that opened when you started Identity Connect.

3. Migrate your configuration.

   1. Copy the following configuration files from the conf directory of the extracted Identity Connect 7.1 installation to the conf directory of your existing Identity Connect 3 installation:

      • managed.json

      • repo.jdbc.json

      • internal.json

      • repo.init.json

      For example:

      cp /path/to/salesforceIdConnect-7/conf/managed.json /path/to/salesforceIdConnect-3/conf/

   2. Replace the Identity Connect 7.1 conf directory with the existing Identity Connect 3 conf directory:

      cp -r /path/to/salesforceIdConnect-3/conf /path/to/salesforceIdConnect-7/

   You now have your existing configuration on the new instance, with the updated versions of the four required configuration files.

4. In the Identity Connect 7.1 conf directory, update all the connector configuration (provisioner.openicf-*.json) files to use the updated connector version ranges. The correct version range for this release is [1.5.19.0,1.6.0.0).

   For example, in provisioner.openicf-AD.json, replace "bundleVersion" : "[1.4.0.0,1.5.0.0)" with "bundleVersion" : "[1.5.19.0,1.6.0.0)".

5. In the Identity Connect 7.1 conf directory, remove the endpoint-reconResults.json file:

   rm /path/to/salesforceIdConnect-7/conf/endpoint-reconResults.json

6. Copy the security files from your Identity Connect 3 installation to your Identity Connect 7.1 installation:

   cp -r /path/to/salesforceIdConnect-3/security /path/to/salesforceIdConnect-7/

7. Copy the startup configuration from your Identity Connect 3 installation to your Identity Connect 7.1 installation:

   cp -r /path/to/salesforceIdConnect-3/resolver /path/to/salesforceIdConnect-7/

8. Copy the data from your Identity Connect 3 installation to your Identity Connect 7.1 installation:

   cp -r /path/to/salesforceIdConnect-3/db /path/to/salesforceIdConnect-7/

9. Update your PostgreSQL repository.

   These steps assume an embedded PostgreSQL repository. If you are using an external PostgreSQL repository, adjust the steps to match your environment.

   1. Embedded repository only: If your PostgreSQL server is not running, start it with the path to the Identity Connect data files:

      cd /path/to/salesforceIdConnect-7/db/openidm/postgres/pgsql-10.5-1/pgsql/bin
      ./pg_ctl start -D /path/to/salesforceIdConnect-7/db/openidm/data

   2. Connect to the PostgreSQL database as the openidm user:

      psql --username openidm --password openidm --port 5432

   3. Run the following commands to update the database schema:

      DELETE FROM openidm.schedulerobjects;
      DELETE FROM openidm.configobjects;
      ALTER TABLE locks ALTER COLUMN objectid TYPE varchar(255);
      DELETE FROM openidm.relationships WHERE firstResourceCollection = 'internal/role' AND firstResourceId = 'openidm-authorized' OR secondResourceCollection = 'internal/role' AND secondResourceId = 'openidm-authorized';

   4. Run the following scripts to update the database:

      \i \path\to\salesforceIdConnect-7\script\updates\00-relationshipresources.sql
      \i \path\to\salesforceIdConnect-7\script\updates\01-syncqueue.sql
      \i \path\to\salesforceIdConnect-7\script\updates\02-importobjects.sql

      psql -U postgres openidm < /path/to/salesforceIdConnect-7/script/updates/00-relationshipresources.sql
      psql -U postgres openidm < /path/to/salesforceIdConnect-7/script/updates/01-syncqueue.sql
      psql -U postgres openidm < /path/to/salesforceIdConnect-7/script/updates/02-importobjects.sql

   5. Embedded repository only: Stop the PostgreSQL server:

      cd /path/to/salesforceIdConnect-7/db/openidm/postgres/pgsql-10.5-1/pgsql/bin
      ./pg_ctl stop -D /path/to/salesforceIdConnect-7/db/openidm/data

10. Start up Identity Connect 7.1:

    \path\to\salesforceIdConnect-7\startup.bat

    /path/to/salesforceIdConnect-7/startup.sh

    Alternatively, start Identity Connect as a Windows service.

1. Download and unzip Identity Connect 7.1.6.

2. Stop the Identity Connect 7.1 instance:

   -> shutdown

   path/to/salesforceIdConnect-71/shutdown.sh

   Note

   On Windows systems, stop the OpenIDM application in the Windows Task Manager, stop the Windows service, or type shutdown in the Felix console that opened when you started Identity Connect.

3. Migrate your configuration.

   Replace the 7.1.6 conf directory with the existing 7.1 conf directory:

   cp -r /path/to/salesforceIdConnect-71/conf /path/to/salesforceIdConnect-716/

4. Copy the security files from your Identity Connect 7.1 installation to your Identity Connect 7.1.6 installation:

   cp -r /path/to/salesforceIdConnect-71/security /path/to/salesforceIdConnect-716/

5. Copy the startup configuration from your Identity Connect 7.1 installation to your Identity Connect 7.1.6 installation:

   cp -r /path/to/salesforceIdConnect-71/resolver /path/to/salesforceIdConnect-716/

6. Copy the data from your Identity Connect 7.1 installation to your Identity Connect 7.1.6 installation:

   cp -r /path/to/salesforceIdConnect-71/db /path/to/salesforceIdConnect-716/

7. Update the bundleVersion for all Salesforce connector configuration files (provisioner.openicf-orgID.json) to one of the following:

   • To use a version range for this release, [1.5.19.0,1.6.0.0).

   • To use the specific version for this release, 1.5.20.19.

8. Start up Identity Connect 7.1.6:

   \path\to\salesforceIdConnect-716\startup.bat

   /path/to/salesforceIdConnect-716/startup.sh

   Alternatively, start Identity Connect as a Windows service.

1. Download and unzip Identity Connect 7.1.

2. Stop the Identity Connect 3 instance:

   -> shutdown

   path/to/salesforceIdConnect-3/shutdown.sh

   Note

   On Windows systems, stop the OpenIDM application in the Windows Task Manager, stop the Windows service, or type shutdown in the Felix console that opened when you started Identity Connect.

3. Migrate your configuration.

   1. Copy the following configuration files from the conf directory of the extracted Identity Connect 7.1 installation to the conf directory of your existing Identity Connect 3 installation:

      • authentication.json

      • managed.json

      • repo.jdbc.json

      • internal.json

      • repo.init.json

      • jetty.xml

      For example:

      cp /path/to/salesforceIdConnect-7/conf/managed.json /path/to/salesforceIdConnect-3/conf/

   2. Replace the Identity Connect 7.1 conf directory with the existing Identity Connect 3 conf directory:

      cp -r /path/to/salesforceIdConnect-3/conf/path/to/salesforceIdConnect-7/

   You now have your existing configuration on the new instance, with new versions of the required configuration files.

4. In the Identity Connect 7.1 conf directory:

   1. Update all the connector configuration (provisioner.openicf-*.json) files to use the new connector version ranges. The correct version range for this release is [1.5.19.0,1.6.0.0).

      For example, in provisioner.openicf-AD.json, replace "bundleVersion" : "[1.4.0.0,1.5.0.0)" with "bundleVersion" : "[1.5.19.0,1.6.0.0)".

   2. Remove the endpoint-reconResults.json file:

      rm /path/to/salesforceIdConnect-7/conf/endpoint-reconResults.json

   3. Change the sync.json file as follows:

      In the mappings for Salesforce Groups and Permission Sets only (systemSalesforceGroup_managedAssignment_orgid and systemSalesforcePermissionSet_managedAssignment_orgid), change the source assignmentOperation and unassignmentOperation values from:

      "assignmentOperation": "addToPickList",
             "unassignmentOperation": "removeFromTarget"

      to:

      "assignmentOperation": "noOp",
             "unassignmentOperation": "noOp"

      When you have made this change, click Refresh to run a reconciliation for each of these objects—Permission Sets and Groups— to ensure that the new assignments are propagated.

5. Copy the security files from your Identity Connect 3 installation to your Identity Connect 7.1 installation:

   cp -r /path/to/salesforceIdConnect-3/security /path/to/salesforceIdConnect-7/

6. Copy the startup configuration from your Identity Connect 3 installation to your Identity Connect 7.1 installation:

   cp -r /path/to/salesforceIdConnect-3/resolver /path/to/salesforceIdConnect-7/

7. Copy the data from your Identity Connect 3 installation to your Identity Connect 7.1 installation:

   cp -r /path/to/salesforceIdConnect-3/db /path/to/salesforceIdConnect-7/

8. Update your PostgreSQL repository.

   These steps assume an embedded PostgreSQL repository. If you are using an external PostgreSQL repository, adjust the steps to match your environment.

   1. Embedded repository only: If your PostgreSQL server is not running, start it with the path to the Identity Connect data files:

      cd /path/to/salesforceIdConnect-7/db/openidm/postgres/pgsql-10.5-1/pgsql/bin
      ./pg_ctl start -D /path/to/salesforceIdConnect-7/db/openidm/data

   2. Connect to the PostgreSQL database as the openidm user:

      psql --username openidm --password --port 5432
      Password: openidm

   3. Run the following commands to update the database schema:

      DELETE FROM openidm.schedulerobjects;
      DELETE FROM openidm.configobjects;
      ALTER TABLE locks ALTER COLUMN objectid TYPE varchar(255);
      DELETE FROM openidm.relationships WHERE firstResourceCollection = 'internal/role' AND firstResourceId = 'openidm-authorized' OR secondResourceCollection = 'internal/role' AND secondResourceId = 'openidm-authorized';

   4. Run the following scripts to update the database:

      \path\to\salesforceIdConnect-7\db\openidm\postgres\pgsql-10.5-1\pgsql\bin\psql -U openidm -W -p 5432 < \path\to\salesforceIdConnect-7\script\updates\00-relationshipresources.sql
      \path\to\salesforceIdConnect-7\db\openidm\postgres\pgsql-10.5-1\pgsql\bin\psql -U openidm -W -p 5432 < \path\to\salesforceIdConnect-7\script\updates\01-syncqueue.sql
      \path\to\salesforceIdConnect-7\db\openidm\postgres\pgsql-10.5-1\pgsql\bin\psql -U openidm -W -p 5432 < \path\to\salesforceIdConnect-7\script\updates\02-importobjects.sql

      psql -U openidm -W -p 5432 < /path/to/salesforceIdConnect-7/script/updates/00-relationshipresources.sql
      psql -U openidm -W -p 5432 < /path/to/salesforceIdConnect-7/script/updates/01-syncqueue.sql
      psql -U openidm -W -p 5432 < /path/to/salesforceIdConnect-7/script/updates/02-importobjects.sql

   5. Embedded repository only: Stop the PostgreSQL server:

      cd /path/to/salesforceIdConnect-7/db/openidm/postgres/pgsql-10.5-1/pgsql/bin
      ./pg_ctl stop -D /path/to/salesforceIdConnect-7/db/openidm/data

9. Start up Identity Connect 7.1:

   \path\to\salesforceIdConnect-7\startup.bat

   /path/to/salesforceIdConnect-7/startup.sh

   Alternatively, start Identity Connect as a Windows service.

In this procedure, the 2.1 installation is referenced at /path/to/salesforceIdConnect-21 and the version 7.1 installation at /path/to/salesforceIdConnect-7. The procedure assumes that your existing (2.1) Identity Connect is up and running:

1. Download and unzip Identity Connect 7.1.

2. Copy the keystore and truststore from your Identity Connect 2.1 instance to your Identity Connect 7.1 installation.

   For example:

   cd /path/to/salesforceIdConnect-7/
   cp /path/to/salesforceIdConnect-21/security/keystore.jceks security/
   cp /path/to/salesforceIdConnect-21/security/truststore security/

3. Import Identity Connect's generated certificate from the keystore into the truststore:

   cd /path/to/salesforceIdConnect-7/security
   keytool \
   -importkeystore \
   -srcalias openidm-localhost \
   -srckeystore keystore.jceks \
   -destkeystore truststore \
   -srcstoretype jceks
   Enter destination keystore password: changeit
   Enter source keystore password: changeit
   Existing entry alias openidm-localhost exists, overwrite? [no]:  yes

   Enter yes at the prompt to overwrite the existing certificate in the truststore.

4. Change to the Identity Connect 7.1 installation directory and run the setup:

   cd /path/to/salesforceIdConnect-7
   ./setup.sh
   *** Identity Connect basic setup ***
   SSL port to listen on for Identity Connect (default 8443): 9443
   Use embedded Postgres as data source for Identity Connect y/n (default "y")?
   Postgres port to connect to (default 5432):
   Setup complete.
   Start the Identity Connect server y/n (default "y")?
   Starting Identity Connect. Point a browser at
   https://hostname.domain.com:9443/

   Important

   If you are installing Identity Connect 7.1 on the same host as the previous version, be sure to specify a different port to the one that you used for Identity Connect 2.1.

5. Migrate the connection configuration.

   This step reads the connection details from your Identity Connect 2.1 instance, and creates the same connection configuration on the new instance.

   Run the configure action on the migration endpoint, specifying the hostname and credentials for your instance. You can run this action as user anonymous:

   curl \
   --insecure \
   --header "X-OpenIDM-Username: anonymous" \
   --header "X-OpenIDM-Password: anonymous" \
   --header "Content-Type: application/json" \
   --request POST \
   --data '{
     "instanceUrl" : "https://localhost:8443/openidm/",
     "userName" : "bjensen",
     "password" : "Passw0rd",
     "authType" : "idm_headers"
   }' \
   "https://localhost:9443/openidm/endpoint/migration?_action=configure"

   You can now connect to the new Identity Connect instance using the authentication details of the Active Directory administrative user that you used to configure the old Identity Connect instance.

   Note

   The --insecure option disables certificate validation. In a production environment, use the --cacert option to validate your CA certificate.

6. Migrate the data.

   To migrate your data, you must authenticate as the administrative user from your Identity Connect 2.1 instance:

   curl \
   --insecure \
   --header "X-OpenIDM-Username: bjensen" \
   --header "X-OpenIDM-Password: Passw0rd" \
   --header "Content-Type: application/json" \
   --request POST \
   "https://localhost:9443/openidm/endpoint/migration?_action=migrate"

7. To check the status of a migration in progress, run the following command either as the anonymous user, or an administrative user:

   curl \
   --insecure \
   --header "X-OpenIDM-Username: bjensen" \
   --header "X-OpenIDM-Password: Passw0rd" \
   --header "Content-Type: application/json" \
   --request POST \
   "https://localhost:9443/openidm/endpoint/migration?_action=status"
   {
     "CONFIGURE": {
       "status": "complete",
       "description": "Completed successfully",
       "result": "success"
     },
     "MIGRATE": {
       "status": "complete",
       "description": "Completed successfully",
       "result": [
         {
           "orgId": "00Dq0000000DUfX",
           "name": "Identity Connect"
         }
       ]
     }
   }

8. If you are running Identity Connect as a Windows service, uninstall and reinstall the IdentityConnect service to apply the appropriate changes to the JVM startup parameters. To uninstall and reinstall the service, run these commands after the upgrade:

   cd C:\install-location\salesforceIdConnect\bin
   service.bat /uninstall identityConnect
   Service "IdentityConnect" removed successfully
   service.bat /install identityConnect
   Identity Connect Service successfully installed as "IdentityConnect" service

9. If you are using SAML SSO, log into the Identity Connect 7.1 Admin Console and create a new SAML SSO configuration:

   1. Navigate to the SSO tab.

   2. Click Generate SSO Config.

Configure the Salesforce connector as follows:

1. The Salesforce login URL field specifies the OAuth endpoint that will be used to make the OAuth authentication request to Salesforce.

   • Select Production for a production system. The OAuth endpoint endpoint for a production system is https://login.salesforce.com/services/oauth2/token.

   • Select Sandbox if you are verifying authentication on a test or sandbox organization. The OAuth endpoint for a sandbox system is https://test.salesforce.com/services/oauth2/token.

   • Select Custom to provide your own OAuth endpoint.

2. Enter the consumer key and consumer secret of your Connected App.

3. (Optional) Select Configure Proxy to set the details of your proxy server.

   For more information, see "Connecting to Salesforce Through a Proxy Server".

4. You are redirected to your Salesforce org. Log in and grant access to Identity Connect to connect to your organization.

5. Identity Connect then connects to your Salesforce organization and reconciles your Salesforce profiles with the Identity Connect repository.

   At this point you are asked to set a default Salesforce profile. All users that are synchronized from Active Directory to Salesforce must have at least one Salesforce profile. You configure how users are assigned profiles as part of the Mapping configuration (see "Mapping Data Between Active Directory and Salesforce"). If an Active Directory user is not a member of any of the groups specified during the mapping, that user receives the default profile that you set here.

6. The next step is to set up a mapping configuration between Active Directory and Salesforce. See "Mapping Data Between Active Directory and Salesforce" for more information.

1. Before you start, make sure that you have configured a Connected App for the new organization.

2. To connect to an additional Salesforce organization, select Settings > Manage Salesforce Organizations.

   This page displays any previous organizations that you have connected to this Identity Connect instance.

3. Select New Organization.

4. Follow the steps outlined in "Connecting to Salesforce" to complete the Salesforce connector configuration.

Cloning an organization duplicates an existing configuration into a new organization configuration. Cloning a configuration can save time as it avoids having to recreate the mapping rules for profiles and roles. However, you can clone an organization only if it originates from the same production organization as the original organization. For example, if you have configured a sandbox organization, you can clone this configuration for a new sandbox organization that is based on the same production organization, or for the production organization itself. Within the organization configuration, there are several references to ID values, that are valid only for organizations that are part of the same production organization family. Attempting to clone an organization configuration across different production organization families will result in errors.

By default, live updates and scheduled reconciliation are disabled for a newly cloned organization, regardless of the live update setting for the existing organization. Having updates disabled by default allows you to customize any changes to the new organization configuration before updates start to flow to your Salesforce data. You must manually enable live updates for the cloned organization, as described in "Configuring When Changes are Synchronized".

1. Before you start, make sure that you have a Connected App for the new organization.

2. Select Settings > Manage Salesforce Organizations.

3. Select the drop-down arrow next to the organization whose configuration you want to duplicate, then select Clone.

4. Follow the steps outlined in "Connecting to Salesforce" to complete the Salesforce connector configuration.

To delete the configuration for an organization:

1. Select Settings > Manage Salesforce Organizations.

2. From the dropdown list next to the organization that you want to delete, select Delete.

Configure attribute mapping by following these steps:

1. On the Mapping page, select the Attributes tab.

2. The list of Active Directory attributes in the left hand column indicates those attributes that have been mapped by default. To change the default mapping, select a different Salesforce attribute in the right hand column.

   To map additional Active Directory attributes, select the attributes in the empty fields in the left hand column, and select their corresponding Salesforce attributes in the right hand column.

3. To map additional Salesforce attributes, select the Add Attribute button and select the required Salesforce attribute. The list of attributes in the Salesforce column is populated directly from the Salesforce data store. You cannot specify your own attributes here, but you can add attributes from the Salesforce list, if the default list does not meet your requirements.

   To remove a Salesforce attribute from the mapping, select the drop-down arrow next to the attribute name and select Remove Attribute. Certain attribute mappings are mandatory—these attributes cannot be removed.

4. Use the Script Editor to specify that an Active Directory attribute value must be transformed to set the value for the Salesforce attribute. A transformation script is a JavaScript that takes a source (Active Directory) attribute, and does something with its value to provide the Salesforce attribute value.

   Select the drop-down arrow next to the Active Directory attribute and select View Script Editor.

   For example, the following sample transformation script takes the value of the mail attribute from Active Directory and converts it to lower case to provide the value of the Email attribute in Salesforce. If no value exists for the mail attribute, a null value is inserted as the value in Salesforce:

   source.mail ? source.mail.toLowerCase() : null

   By default, the manager attribute in Active Directory is mapped to the managerID attribute in Salesforce, using the following transformation script:

   require('mappingUtils').getManagerIdForSalesforceUser('00DZ0000009SaxM', source.manager)
       

   The transformation script locates the Active Directory user's manager attribute and looks up the manager's objectGUID, based on the value of his distinguishedName. The script then locates the corresponding SalesforceID of the manager, in the links table, and uses this ID to populate the managerID property in Salesforce.

   Note

   Active Directory attributes can be either single-valued or multi-valued. Multi-valued Active Directory attributes are stored as an array in the connector schema. If you are mapping a Salesforce attribute to a multi-valued Active Directory attribute, your transformation script must take this into account.

   For more information about single and multi-valued attributes, see the MSDN article on Single vs. Multiple Value Attributes.

5. Specify Update Rules to apply conditions under which an attribute in Salesforce will be updated.

   To specify a conditional update rule, select Update Rules from the dropdown menu next to the Salesforce attribute.

   • You can define a conditional update script to prevent an attribute from being updated in Salesforce under certain conditions.

     A conditional update script takes the following form:

     object.attribute operator value
           

     where attribute refers to the source (Active Directory) attribute. The condition is based on the attribute value of the Active Directory entry. The corresponding attribute in Salesforce is updated only if the condition evaluates to true for that entry. The attribute name is case sensitive.

     For example, if all users based in Germany worked for a specific department, you might want to prevent any changes to these users' department attribute in Salesforce. In this example, you would apply a conditional update script to the department attribute in the mapping, which would filter out changes to this attribute for users whose country name (co) attribute was Germany. The following conditional update script on the department attribute would achieve this objective:

     object.co != "Germany"
           

     In other words, update this attribute in Salesforce only if the entry's country attribute is not Germany.

   • By default, Salesforce attribute values are set when a user is created, and when that user is updated. You can specify that the attribute value should be set only when the user is created, by selecting Only when creating a new user from the dropdown list in this window.

     In this case, any updates to a user entry will not reset the Salesforce attribute value for that entry.

     Note that, regardless of the situation you select from this list, if you have defined a conditional update script that returns false for an entry, the attribute value will not be set for that entry.

   • Specify what should happen to the Salesforce attribute in the event that the user does not have the corresponding attribute in their Active Directory user entry. If you enter a value here, the attribute in Salesforce is set to this value if the Active Directory attribute is empty or if the attribute does not exist.

6. When the attribute mapping configuration is complete, select Save to save the mapping.

Configure profile mapping by following these steps:

1. On the Mapping page, select AD Group to Profile.

2. Select one or more Active Directory groups in the left hand column to map to the Salesforce profiles in the right hand column.

   The right hand column lists all possible Salesforce profiles. You do not have to map an Active Directory group to every Salesforce profile.

3. In the event of a user being allocated more than one Salesforce profile, based on the group mapping, you can specify an order of precedence to indicate which profile should be taken into account.

   Reorder the profiles by dragging them up and down to list the profiles in their order of precedence.

4. Select Advanced to specify additional behavior for the group to profile mapping:

   • By default, Identity Connect uses the memberOf LDAP attribute to determine membership of an Active Directory group.

     To change the LDAP group membership attribute, select the Advanced button, then select the attribute to use.

   • By default, Salesforce profiles are set when a user is created, and when that user is updated. You can specify that the profiles should be set only when the user is created, by selecting Only when creating a new user from the dropdown list in this window.

     In this case, any updates to a user entry will not reset the Salesforce profiles for that entry.

   • Specify what should happen to the Salesforce profile in the event that the user is not a member of any of the Active Directory groups that you have mapped on this page.

     If you set a value here, the user obtains this profile ID by default.

5. When you have completed the profile mapping, select Save to apply the mapping.

1. On the Mapping page, select AD Group to Permission Set.

2. No permission sets are displayed by default.

   To add a permission set to be mapped, select Add Permission Set and select the permission set from the list.

   The permission sets in this list are those that you have defined in your Salesforce organization.

   If you add a new permission set in Salesforce, you must Refresh this page for the new permission set to be displayed in the list.

3. Select an Active Directory group to map to the permission set.

   You can select more than one Active Directory group per permission set.

   Click Save to save the new mapping.

4. Repeat this procedure for each Salesforce permission set that you want to map.

1. On the Mapping page, select AD Group to Salesforce Group.

2. No public groups are displayed by default.

   To add a group to be mapped, select Add Group and select the group from the list.

   The groups in this list are those that you have defined in your Salesforce organization.

   If you add a new public group in Salesforce, you must Refresh this page for the new group to be displayed in the list.

3. Select an Active Directory group to map to the Salesforce group.

   You can select more than one Active Directory group per Salesforce group.

   Click Save to save the new mapping.

4. Repeat this procedure for each Salesforce group that you want to map.

1. Change to the Identity Connect configuration directory.

   cd /path/to/salesforceIdConnect/conf

2. Using a text editor, edit the configuration file for your Salesforce organization (provisioner.openicf-org-id.json), and change the value of the maximumConnections property, for example:

   {
       "enabled" : true,
       "configurationProperties" : {
           ...
           "maximumConnections" : 20,
           ....
       }
   }

   The maximumConnections property specifies the maximum size of the HTTP connection pool that is used to connect to Salesforce, in other words, the maximum number of simultaneous requests that a single Identity Connect browser session can make to each Salesforce site (Token and API).

   The default size of the connection pool is 10 connections. Increase the value of this parameter to make more connections available to Identity Connect. Generally, if you are seeing connection errors, doubling the number of connections will prevent such errors.

To change the UI theme, follow these steps:

1. Select Settings at the top right of the Identity Connect administrative interface, then select Customize Theme.

2. Adjust the following settings:

   • Background Color sets the background color across the entire UI.

     Select the required color from the color chart drop down, or enter the hex value (or any CSS valid color value).

   • Primary Color sets the color of primary UI buttons, links and accent colors across the Admin UI.

     Select the required color from the color chart dropdown or enter the hex value (or any CSS valid color value).

   • Logo sets a custom logo for the login screen and in the administrative interface.

     Either drag and drop an image file onto the existing logo or select Upload File and browse for the image file.

     The image is scaled to be 55px in height. All image types, including SVG are supported.

3. When you have completed the customization, select Save to save the new theme.

1. Select Settings at the top right of the Identity Connect window, then select Session.

2. In the Maximum session lifetime field, enter the maximum number of minutes that a session can be live, after the initial login.

3. In the Session idle timeout field, enter the maximum number of minutes that a session can be idle, before the user is logged out automatically.

1. Select Settings at the top right of the Identity Connect window, then select Password Reset.

2. In the Reset Password Link field, enter the URL to which password reset requests should be sent.

1. Connect to the openidm database as the default user openidm:

   psql -U openidm
   Password for user openidm:
   psql (11.2, server 10.5)
   Type "help" for help.

2. Change the username of the openidm user.

   The following command changes the username to ic-admin:

   ALTER USER openidm RENAME TO ic-admin

3. Change the password of the new user.

   The following command changes the password to Passw0rd:

   ALTER USER ic-admin WITH PASSWORD Passw0rd

4. Change the database connection configuration file (/path/to/salesforceIdConnect/conf/datasource.jdbc-default.json) to reflect the new username and password:

   {
       "driverClass" : "org.postgresql.Driver",
       "jdbcUrl" : "jdbc:postgresql://&{openidm.repo.host}:&{openidm.repo.port}/openidm",
       "databaseName" : "openidm",
       "username" : "ic-admin",
       "password" : "Passw0rd",
       ...
   }

5. Restart Identity Connect and make sure that you can connect.

1. On each host that will contain an Identity Connect instance, unpack the contents of the .zip file into the install location, but do not set up Identity Connect.

2. Configure each Identity Connect instance for an external PostgreSQL database, as described in "Configuring Identity Connect With an External PostgreSQL Repository".

   You need to execute the schema scripts (those scripts in /path/to/salesforceIdConnect/db/postgresql/scripts) once only because all the instances will use the same database.

   When you set up each Identity Connect instance, make sure that you specify the same external PostgreSQL database. If you have already set up an instance and want to point to a different database, edit the /path/to/salesforceIdConnect/conf/datasource.jdbc-default.json file and set the jdbcUrl property. For example:

   "jdbcUrl" : "jdbc:postgresql://&{openidm.repo.host}:&{openidm.repo.port}/openidm",

   where &{openidm.repo.host} specifies the host on which the PostgreSQL database is located.

3. Specify a unique node ID for each instance by setting the value of openidm.node.id in the resolver/boot.properties file of the instance. For example:

   openidm.node.id = node1

   You can set any value for the openidm.node.id, as long as the value is unique within the cluster. The cluster manager detects unavailable instances by their node ID.

   You must set a node ID for each instance, otherwise the instance fails to start. The default resolver/boot.properties file sets the node ID to openidm.node.id=node1.

4. Set the cluster configuration.

   The cluster configuration is defined in the conf/cluster.json file of each instance. By default, configuration changes are persisted in the repository so changes that you make in this file apply to all nodes in the cluster.

   The default version of the cluster.json file assumes that the cluster management service is disabled:

   {
       "instanceId" : "&{openidm.node.id}",
       "instanceTimeout" : 30000,
       "instanceRecoveryTimeout" : 30000,
       "instanceCheckInInterval" : 5000,
       "instanceCheckInOffset" : 0,
       "enabled" : false
   }

   • The instanceId is set to the value of each instance's openidm.node.id that you set in the previous step.

   • The instanceTimeout specifies the length of time (in milliseconds) that a member of the cluster can be "down" before the cluster manager considers that instance to be in recovery mode.

     Recovery mode indicates that the instanceTimeout of an instance has expired, and that another instance in the cluster has detected that event.

     The scheduler component of the second instance then moves any incomplete jobs into the queue for the cluster.

   • The instanceRecoveryTimeout specifies the time (in milliseconds) that an instance can be in recovery mode before it is considered to be offline.

     This property sets a limit after which other members of the cluster stop trying to access an unavailable instance.

   • The instanceCheckInInterval specifies the frequency (in milliseconds) that instances check in with the cluster manager to indicate that they are still online.

   • The instanceCheckInOffset specifies an offset (in milliseconds) for the check-in timing, when multiple instances in a cluster are started simultaneously.

     The check-in offset prevents multiple instances from checking in simultaneously, which would strain the cluster manager resource.

   • The enabled property specifies whether the cluster management service is enabled when you start the server. This property is set to false by default.

     If you have enabled the cluster manager, do not disable it while clustered nodes are running.

5. On all instances except the first instance, prevent Identity Connect from reading its configuration from the configuration files.

   In the conf/system.properties file on each instance, uncomment the line openidm.fileinstall.enabled=false.

   This forces Identity Connect to read its configuration only from the repository, in this case, the repository of the first instance.

   openidm.fileinstall.enabled=false

6. Start up and configure the first Identity Connect instance.

   Make sure that when you initially access this Identity Connect instance, you use the FQDN (https://host.domain:8443) and not localhost.

7. Configure each node in the cluster to use the same keystore and truststore.

   After you have started and configured the first instance, copy the initialized keystore (/path/to/salesforceIdConnect/security/keystore.jceks) and truststore (/path/to/salesforceIdConnect/security/truststore) to all other instances in the cluster.

8. Make sure that all additional instances have access to the shared PostgreSQL database.

9. Start up the additional instances.

   Additional instances read the configuration from the first instance, so requests to https://host2.example.com:8443/#/connect/login should read the existing Identity Connect configuration from the first host.