Salesforce Identity Connect: Active Directory Sync Explained

💬 In plain words: Identity Connect is a synchronization bridge between Microsoft Active Directory (AD) and Salesforce. It watches AD and automatically mirrors joiners, movers, and leavers into Salesforce user records. When someone leaves the company and IT disables their AD account, their Salesforce access shuts off automatically without waiting for a manual ticket.

📌 Worked example: HR notifies IT that Ramesh is leaving the company, and an administrator disables his profile in Active Directory at 5:00 PM. Identity Connect detects the directory change and sets IsActive = false on his Salesforce user record minutes later. New joiners get provisioned from their AD security groups, and internal movers receive updated permission sets automatically. Active Directory holds the truth, and Salesforce mirrors it.

🔑 Key Points

• Directory-Driven Lifecycle: Identity Connect maps Active Directory users and security groups directly to Salesforce User records, profiles, roles, and permission sets.
• Standing Synchronization: Changes flow through continuous polling (near real-time) or scheduled sync jobs, rather than waiting for a user to log in.
• Automatic De-provisioning: Disabling or removing a user from an authorized AD group immediately deactivates or freezes their Salesforce account, closing a major security gap left by login-only tools.
• Infrastructure Overhead: It requires a dedicated add-on license and a self-managed Linux or Windows server positioned between your corporate network and Salesforce.
• Retirement Status: Salesforce is retiring Identity Connect and only supports existing contracts until they expire. You must understand it for legacy org maintenance and architect exams, while planning migrations to SCIM or cloud identity providers for new builds.

🏗️ Concept: How Identity Connect Works

In many traditional enterprises, Microsoft Active Directory (AD) is the central registry for workforce identity. Every time an employee joins the company, changes departments, or resigns, IT updates their status and group memberships in AD first. Without automated provisioning, a Salesforce administrator has to repeat those exact same steps manually inside Salesforce Setup.

Salesforce Identity Connect solves this duplication by making Active Directory the single source of truth for user management. It runs as a standalone Java service on a server (either on-premises behind your corporate firewall or in a private cloud) that connects to your local AD domain controllers via LDAP (Lightweight Directory Access Protocol) and communicates with Salesforce over HTTPS REST and SOAP APIs.

Let's look at the core architectural flow shown in the diagram above:

Identity Connect Architecture
  Microsoft AD  ── (on-prem Identity Connect server) ──>  Salesforce
  ├─ syncs AD users + group membership -> SF users + profile/permset
  ├─ joiner/mover/leaver auto-provision & deactivate
  ├─ real-time polling or scheduled sync
  └─ optional AD-based SSO · needs its own license + on-prem server

When you configure Identity Connect, you map AD attributes (such as givenName, sn, and mail) to standard or custom fields on the Salesforce User object. More importantly, you map AD security groups to Salesforce entitlements. Adding an employee to an AD group like SF_Sales_EMEA instructs Identity Connect to create their Salesforce account, assign the appropriate Sales profile, place them in the EMEA role hierarchy, and attach specific permission sets.

Beyond user provisioning, Identity Connect can also act as an Identity Provider (IdP) using SAML 2.0. This allows employees to log in to Salesforce using their corporate Windows credentials via Single Sign-On (SSO), though many organizations prefer to pair it with dedicated SSO tools or Salesforce My Domain Policies and Multi-Factor Authentication (MFA).

🧠 Core Rule — Identity Connect vs. JIT: Identity Connect runs a standing AD-to-Salesforce directory sync for group-driven joiners, movers, and leavers. Just-in-Time (JIT) provisioning only creates or updates a user at the exact moment they log in with a SAML assertion. Use directory sync for full lifecycle governance; use JIT when you only need login-time creation.

⚖️ Provisioning Comparison: Identity Connect vs. JIT vs. SCIM

Choosing the right provisioning mechanism is a classic trade-off in Salesforce identity architecture. While Just-in-Time (JIT) provisioning and SCIM (System for Cross-domain Identity Management) also automate user records, they operate under very different triggers and architectural assumptions.

• Just-in-Time (JIT) Provisioning: Piggybacks on SAML 2.0 Single Sign-On. When a user authenticates at the Identity Provider, the IdP sends user attributes inside the SAML assertion to Salesforce. Salesforce reads the XML payload and creates or updates the user on the fly. The catch: JIT is purely reactive to login events. When someone leaves the company and loses IdP access, they can no longer log in via SAML—meaning no SAML assertion is ever sent to tell Salesforce to deactivate them. Their User record stays active, continuing to consume a paid license, receive scheduled report emails, and remain eligible for direct API token access until an admin intervenes.
• Identity Connect: Runs an active, background synchronization directly from on-premises Active Directory. Users exist in Salesforce before their first login (so managers can add them to territories or queues on day one), and leavers are deactivated immediately when their AD account is disabled.
• Cloud IdP + SCIM / Native Connectors: Modern cloud directories (such as Microsoft Entra ID, Okta, or Ping Identity) push user lifecycle events directly to Salesforce’s standard /services/data/vXX.X/scim/v2/Users REST endpoints. Because Salesforce is retiring Identity Connect, SCIM-based provisioning and cloud connectors are the standard choice for new implementations.

🛠️ Worked Example: Joiner, Mover, and Leaver Sync

📋 Illustrative implementation scenario: The following walkthrough demonstrates how an enterprise maps Active Directory changes to Salesforce user states, and how an administrator verifies the result in a sandbox environment before relying on the sync.

Suppose an organization manages all employee access through on-premises Active Directory security groups. To automate Salesforce administration, the team configures three core mappings inside the Identity Connect web administration console:

1. Joiner (Provisioning): A new representative, Priya, joins the Inside Sales team. IT adds her AD user account to the AD_SF_InsideSales group. During the next sync cycle, Identity Connect reads her AD attributes and inserts a Salesforce User record with Profile = Custom: Inside Sales and IsActive = true.
2. Mover (Entitlement Update): Six months later, Priya is promoted to Sales Manager. IT moves her in AD from AD_SF_InsideSales to AD_SF_SalesManagers. Identity Connect detects the group change, removes her old Inside Sales permission set assignments, and assigns the Sales_Manager_Approvals permission set.
3. Leaver (De-provisioning): When an employee resigns, HR triggers an AD account disablement. Identity Connect's policy is configured to either Deactivate (IsActive = false) or Freeze (UserLogin.IsFrozen = true) the matching Salesforce user.

Verifying Provisioning and De-provisioning in Salesforce

To verify that your synchronization rules are working as expected in your own testing environment, inspect the audit trail and user login states using SOQL in the Developer Console or Salesforce Inspector. Note that the query below is a diagnostic snippet to run in your org after triggering an AD test sync:

// Diagnostic SOQL excerpt: Verify user activation and freeze status
// Run in Developer Console Query Editor or Salesforce CLI
SELECT Id, Username, IsActive, Profile.Name, LastModifiedDate, LastModifiedBy.Name
FROM User
WHERE FederationIdentifier = 'ramesh.kumar@company.example'
LIMIT 1

If your de-provisioning rule is set to Freeze rather than immediately deactivate (which is necessary when the user is the sole Default Lead Creator, Web-to-Case owner, or recipient of workflow emails), check the UserLogin object as well:

// Diagnostic SOQL excerpt: Check if the user account is frozen
SELECT Id, UserId, IsFrozen, IsPasswordLocked
FROM UserLogin
WHERE UserId = '005XXXXXXXXXXXXAAA'

In a working setup, LastModifiedBy.Name on the updated user record will show the dedicated integration user assigned to your Identity Connect Connected App, and the timestamp will match your scheduled or polling sync window.

⚠️ Common Mistakes and Operational Traps

🚨 Watch out for these failure modes:

• Hard-Deactivating Record Owners in Automated Rules: Salesforce blocks you from setting IsActive = false on a user who is referenced in active assignment rules, lead settings, or custom hierarchy fields. If Identity Connect tries to hard-deactivate that user, the API call fails and the user remains active! Configure Identity Connect to Freeze the user upon deactivation failure, or default to freezing leavers until an admin transfers their ownership dependencies.
• Single Point of Failure on the Sync Server: If the local server hosting Identity Connect crashes, runs out of disk space from unrotated logs, or loses its SSL certificate, synchronization stops silently. Always deploy Identity Connect in a clustered high-availability (HA) setup and monitor the sync logs actively.
• Recommending Identity Connect for New Builds: Because Salesforce announced the retirement of Identity Connect, you cannot purchase new subscriptions for net-new implementations. If an architect exam question explicitly asks for a native Salesforce-provided on-premises AD bridge, Identity Connect is still the textbook answer—but in real-world consulting, you should propose Microsoft Entra Connect with SCIM or an enterprise cloud IdP.

🧭 360 Card — Identity Connect

Rule: When on-premises Active Directory is the source of truth and access follows AD groups, mirror the directory automatically rather than rebuilding user management manually in Salesforce.
Gain: Joiners, movers, and leavers flow automatically. HR or IT disables the AD account, and the Salesforce user deactivates or freezes minutes later without manual tickets.
Price: Infrastructure and license overhead. A dedicated server must be installed, patched, monitored, and kept highly available on-premises or in a private cloud.
Limits: It is a standing directory sync driven by AD group membership, not a per-login event. Furthermore, Salesforce is retiring the product, limiting it to existing licensed customers.
Mirror — JIT from a SAML assertion: Requires zero server infrastructure to run, but provides zero automated leaver de-provisioning.
Later (Migration Path): As estates move to cloud identity providers (Microsoft Entra ID, Okta), SCIM REST APIs or native cloud connectors replace Identity Connect entirely.
At Volume: Group-driven provisioning scales cleanly to thousands of users, provided the on-premises server cluster has an active availability plan and respects Salesforce API limits.

💬 Core Q&A and Architecture Scenarios

Q: The workforce is entirely managed in Microsoft Active Directory, with access driven by AD groups. They want Salesforce users to appear, update, and deactivate automatically. What do you propose over plain JIT?

🎯 Say this first: "Propose directory-driven provisioning—historically Salesforce Identity Connect for on-premises AD, or an Entra ID / SCIM connector for modern builds. Unlike JIT, directory sync ties AD group membership directly to create, update, and deactivate actions so leavers lose Salesforce access the moment AD disables them."

A: For an existing on-premises Active Directory environment (or in the context of the Salesforce Identity and Access Management Architect exam), the purpose-built solution is Salesforce Identity Connect. It runs as a server component between Active Directory and Salesforce, treating AD as the authoritative source of truth and synchronizing AD users and group memberships directly into Salesforce:

• Joiners: Adding a user to the right AD security group automatically creates their Salesforce User record prior to their first login.
• Movers: Changing a user's AD groups automatically updates their Salesforce profile, role, and permission sets.
• Leavers: Disabling the user in AD automatically deactivates or freezes them in Salesforce.

You choose this over plain Just-in-Time (JIT) provisioning for one decisive security reason: JIT only creates and updates users when a SAML assertion arrives during an individual login, meaning JIT has no de-provisioning capability at all. A standing directory sync enforces complete joiner-mover-leaver governance. Be sure to flag two operational costs to stakeholders: the extra add-on license and the on-premises server infrastructure the IT team must maintain (or advise migrating to Microsoft Entra ID with Salesforce's SCIM connector given Identity Connect's retirement).

Q: What is the operational downside of Identity Connect that the client should budget for?

A: It introduces a stateful on-premises (or privately hosted) server component into your architecture. Someone on the infrastructure team has to install the software, manage Java updates, patch the operating system, rotate certificates, monitor sync error logs, and configure high availability. It also carries a separate license cost. If that server goes offline, your user provisioning and AD-based SSO stop working until it recovers. It requires the exact same operational discipline as any enterprise middleware. For organizations that do not want to maintain server infrastructure, a cloud-native IdP using SCIM provisioning is much lighter to operate.

🧪 Self-Check Question: A company uses SAML Single Sign-On with Just-in-Time (JIT) provisioning enabled, and does not use Identity Connect or SCIM. When an employee is fired and their account is disabled in the Identity Provider, what happens to their Salesforce User record?

Answer: Nothing happens to the Salesforce User record—it remains IsActive = true.
Explanation: While the former employee can no longer log in through the SSO portal, JIT only executes when a valid SAML assertion is posted to Salesforce during login. Because a disabled user never completes a login, Salesforce never receives a signal to deactivate them. They continue to consume a license and remain active in the org unless you implement a standing sync like Identity Connect, SCIM, or an automated API de-provisioning job.

🔗 Next Concept Follow-Up: Moving to SCIM

Q: Since Salesforce is retiring Identity Connect, how does SCIM handle the exact same joiner-mover-leaver lifecycle without an on-premises Identity Connect server?

A: SCIM (System for Cross-domain Identity Management) is an open REST and JSON standard that Salesforce supports natively out of the box. Instead of installing a Salesforce-specific software agent on a local server to poll Active Directory, you connect your directory to a cloud identity provider (such as Microsoft Entra ID or Okta). When HR or IT updates a user or group in the directory, the cloud IdP makes a standard HTTPS POST, PATCH, or DELETE call directly to Salesforce's /services/scim/v2/Users endpoint using an OAuth 2.0 Connected App. You get the exact same automated create, permission update, and leaver deactivation benefits—without managing a dedicated middleware server.