Learn About Deployment Considerations

Now let’s take a look at the network resources required to deploy Identity Connect. Here’s where the rubber hits the road, so to speak. How do you deploy Identity Connect in your network? Where does it reside on the network? Do you need a dedicated server to run Identity Connect? How do you ensure high availability?

As a Salesforce admin, you might not care. But you can be sure that your network engineer does. This unit answers questions your IT department can have. Jedeye Technologies wants to deploy Identity Connect correctly the first time. With the information in this unit, you can help.

Identity Connect is on-premises software that sits behind your firewall and pushes data to Salesforce. Identity Connect’s server runs within the corporate network and communicates with the AD server over LDAP(S). It communicates with in-the-cloud Salesforce over HTTPS. Work with your networking engineer to ensure that the appropriate firewall ports are open so that Identity Connect can connect to both AD and Salesforce.

Not really. If you’re installing Identity Connect on a shared server, make sure that Identity Connect has adequate resources and is running the supported version of Java.

Check that all other apps can run on the same version. Or install a separate instance of Java specifically for Identity Connect.

If you're using Identity Connect’s default OrientDB database, you can’t run more than one instance on the same server. So if you want to support multiple test environments on a single machine, use an external database like MySQL or MS SQL.

Identity Connect is on-premises software that sits behind your firewall and pushes data to Salesforce.

Most companies use firewalls to control inbound connections coming from outside their corporate network while allowing outbound traffic. That is, you can access the Internet from the office, but you’re required to be on a VPN to access internal resources from your home or coffee shop.

The demilitarized zone (DMZ) is a subnetwork that separates your internal network from other untrusted networks, like the Internet. But it’s still on-premises, within the corporate network. Instead of installing Identity Connect behind the firewall, you can install it in the DMZ.

When using Identity Connect for SSO, put Identity Connect in the DMZ if:

• Your users log in to Salesforce from outside your trusted network. This way, your external users can access the Identity Connect login page without having to use a VPN.
• You want users to log in to Salesforce from a mobile device. Otherwise, your users must be on a mobile VPN.

Sure. Identity Connect is designed to work with multiple Salesforce orgs. You can set up Identity Connect to manage all these orgs simultaneously.

Each org has its own Identity Connect mapping so you can control the user’s attributes and entitlements separately for each org.

Jedeye Tech has employees on planets across the galaxy that they manage from a central AD on the planet Aerial. They can have a separate Salesforce org for each planet while managing all users from the AD and Identity Connect servers on Aerial.

Identity Connect is designed to work with a single AD domain. But you can still use Identity Connect with multiple domains.

Jedeye Technologies can benefit from a multiple domain configuration to help with your recent acquisition of Treble Association because Treble uses AD too. You can use AD to give Treble Association users immediate access to Salesforce with their AD credentials. You don’t have to require a Salesforce username and password.

You have two options to configure Identity Connect across two AD domains. Configure one Identity Connect environment for all domains using a global catalog, or configure a new Identity Connect for each domain.

One Identity Connect to Serve All AD Domains

To set up a single Identity Connect environment, use a global catalog. A global catalog is a special domain controller that aggregates all user and group information from all AD domains into a central repository. (A domain controller is a computer on which AD is installed.)

Identity Connect can connect to the catalog to manage all users and groups from both directories.

Individual Identity Connect Environments for Each AD Domain

When you set up a separate Identity Connect for each AD domain, one Identity Connect environment connects to the Jedeye Tech AD domain. The other environment connects to the Treble Association AD domain.

Here at Salesforce, we used this Identity Connect configuration when we integrated Salesforce with ExactTarget. We set up a separate instance of Identity Connect on ExactTarget to give them immediate access. Then we gradually migrated them to our Salesforce domain.

Deploy an Identity Connect cluster of multiple servers to ensure Identity Connect works even when one server goes down. This way, you can make sure Identity Connect is always available on your network.

If your primary server goes down, the backup servers can still handle requests. This is called a high-availability cluster.

With a high-availability cluster, the primary Identity Connect instance writes all your configuration changes to the database. You can install Identity Connect on a secondary server that continues processing in case the primary server fails. If the primary instance goes down, and the database is still available, the secondary server takes over.

If you’re using Identity Connect only for provisioning, there’s a chance you don’t need high-availability cluster. It depends on your situation. In the unlikely event that the server goes down, new hire provisioning and terminations aren’t happening at that time. If you’re willing to take this risk, the upside is a simpler configuration.

If you're using Identity Connect for SSO, set up Identity Connect in a multi-instance cluster to avoid a single point of failure. If the entire company can’t log in to Salesforce, it’s a big deal.

To set up a high-availability cluster configuration in larger orgs, we recommend configuring a load balancer and a MySQL database. The load balancer distributes SSO login requests across each instance of Identity Connect. If one goes down, the load balancer redirects the user to log in to another instance. The MySQL database is used for storing Identity Connect’s configurations on the secondary server.

An advantage to this configuration is that you’re not charged extra if you install Identity Connect on multiple servers. Competing products charge per CPU. Salesforce licensing is based on the number of users, not the hardware. Decide your Identity Connect configuration based on the degree of disaster recovery you require—not the price.

You can use a load balancer to ensure that authentication and provisioning aren’t impacted when an AD domain controller is taken offline.

However, if you use a load balancer and LiveSync (live update), we recommend that you set it up to be sticky to a specific domain controller. Using the same domain controller as long as the controller is online makes the LiveSync process more reliable.

An advantage of Identity Connect is how easy it is to use to configure SSO. With a single click, your users are set up.

After you map your attributes, Identity Connect has all the necessary information to enable SSO.

If you already have an SSO solution, you can use your solution for SSO while using Identity Connect for provisioning. Identity Connect works well with any existing SSO solution.

No. You can set up Identity Connect to manage multiple production orgs. And you can set up Identity Connect to manage multiple nonproduction orgs. But you can’t mix production and sandbox orgs in one Identity Connect environment.

Here’s why.

• On sandboxes, you’re often not as strict about upkeep. If someone deletes permission sets or roles mapped in a sandbox, Identity Connect still tries to manage them. Failures pile up. Throughput slows to a crawl. Nothing’s provisioned. Ugh.
• By keeping production and sandbox orgs separate, it’s easier for Salesforce Support to determine whether a sandbox configuration issue impacts a production org.

When you get into full-blown configuration testing in your sandbox, most customers set up a test Identity Connect configuration to either their Full or User Acceptance Testing (UAT) sandbox.

Upsides to a Full sandbox:

• Your maintenance is minimal. Instances are refreshed less frequently, and users are often the same users that are in production.
• You can use your production AD account.

Upside to a UAT sandbox: it’s a full replica of production. Use a UAT sandbox:

• As a final validation before releasing to production
• To test any patches for Identity Connect to avoid impacting production

• Sandbox Types and Templates
• API Limits
• Salesforce Identity Connect Implementation Guide