Technical overview
This page is for identity architects and MIM consultants who want to know what's under the hood: why there is still a place for a synchronization engine, how Sinkrona Connect is built, what happens in a run, and how it stays correct when things go wrong. No code, just the moving parts.
Identity has moved a long way in fifteen years. Sign-in happens in the cloud, access is requested in a portal, and governance suites review who has what. It's easy to conclude that the synchronization engine belongs to the past. Look at any real environment, though, and the same picture appears: an HR system that knows who is employed, a directory that knows who can sign in, a handful of databases and LDAP directories behind business applications, a growing list of SaaS apps, and at least one in-house system with its own idea of a user.
Each of those systems holds part of the truth about the same person. Somebody has to
Microsoft Entra cloud sync and app provisioning do a good job of moving identities from a source into Entra ID and on to SaaS apps, and you should use them for that. Identity governance suites, Microsoft Entra ID Governance among them, are good at deciding what access should exist. Neither is built to be the many-to-many hub between all your systems, with one combined view of each person, precedence per attribute and code where the rules get unusual. That hub is what the MIM Synchronization Service has been for many organizations, and it's the part that needs a new home when MIM 2016 reaches the end of support.
Sinkrona Connect is that home. It sits next to the cloud tools, not in their way: Entra ID is one connected system among the others, and a governance product (including our own Sinkrona Compass) connects through a management agent like any other system.
Sinkrona Connect is deliberately small. One host process does the work, one database holds the state, and everything else talks to it through the same REST API.
A .NET 10 service runs the synchronization engine, the built-in scheduler and the REST API. It runs as a Windows service, as a Linux process or in a container. Scheduled runs and manual runs go through the same run pipeline, so there is only one way a run can happen.
Configuration, connector spaces, the metaverse, run history, pending exports, errors and the audit log live in one MongoDB database. Documents are human-readable, so you can look at an object with any MongoDB tool when you need to. No SQL Server licence is needed.
The browser portal is an Angular application served by the engine. It has no database access and no special commands: every button is an API call your scripts can make too. It shows what the server says and never works out the engine's state on its own.
Each connector and rules extension is loaded in its own .NET load context inside the engine, so their dependencies never clash. Every call is time-boxed and protected by a circuit breaker: a misbehaving connector fails its own run step, not the engine.
The concepts are the ones from MIM Sync, on purpose. Every connected system has a management agent with its own connector space: a staging copy of the objects in that system, as last imported and as Sinkrona wants to export them. The metaverse holds one combined object per person, group or other identity, linked to its connector space objects (connectors). An object that isn't linked to anything is a disconnector, and the Joiner lets an operator link and unlink objects by hand.
Underneath, it's built for size. All connector space objects share one collection, kept apart by management agent and indexed on the anchor, and all metaverse objects share another. Searches and run history are paged on indexes, so a page of results reads about a page of documents, whether you have ten thousand objects or a few million. The performance tests in every build check exactly that against the database's own query plans.
Each metaverse value remembers where it came from: the management agent, the rule and the run that set it. The portal shows that lineage on every object, so "why does this person have this title?" has an answer.
Run profiles combine the same steps as in MIM: import, synchronization and export, as full or delta steps. Data always moves in pages, and a page is the unit of work.
The connector reads the connected system page by page, all objects (full) or only changes since the last watermark (delta). Changes are staged in the connector space as pending imports. The engine never loads a whole connector space into memory.
For each page: deletions first, then join and projection, then import attribute flow with precedence. The changed metaverse objects are written in one bulk write. That's the page's commit point.
From the committed metaverse objects: reverse join to existing accounts, provisioning and deprovisioning, and export attribute flow. The result is a pending export per connector: what the system should look like.
Pending exports go to the connector in batches. The next import reads the values back and confirms them; a value that didn't stick is flagged and staged again.
Per management agent you can turn on per-object sync: a change that arrives on import is synchronized and staged for export right away instead of waiting for the next synchronization run. Preview runs the real synchronization of one object inside a database transaction and rolls it back, so you see exactly what would change in the metaverse and every connected system before anything is written. If you like the result, you commit it.
An identity engine writes to the systems people use to sign in and get paid, so it has to be boring in the best sense. Sinkrona Connect treats synchronization as an explicit state machine with clear commit points, and is built so that repeating any step gives the same result as running it once.
Two tiers of rules, one SDK, and no privileged connectors.
Join and projection rules, attribute flows and provisioning rules are configured in the portal and stored as JSON. Expressions use a library of more than a hundred built-in transforms for text, names, dates, DNs and Active Directory values. They are pure functions, compiled once per configuration version and evaluated in memory, with no database reads per object.
Management agent and metaverse rules extensions in C# handle what the transforms can't: advanced flows, join resolution, provisioning and deprovisioning decisions. The interfaces match the ones you wrote for MIM, so most existing extensions move over with a recompile.
Connectors use ECMA2-style interfaces on modern .NET: capabilities, parameters, schema discovery, containers, paged import with a watermark, batched export, passwords. All calls are asynchronous and can be cancelled. Existing ECMA2 connectors are ported by recompiling against the SDK.
Active Directory, Entra ID, LDAP, SQL Server, MySQL, PostgreSQL, REST, SCIM, PowerShell, CSV and more are built only on the public SDK. Anything they do, a third-party connector can do. Each one is self-contained, so updating one never changes another.
Every operator action is a versioned REST call (/api/v1) with an OpenAPI contract: runs, joins, preview, retries, password resets, configuration export and import. Within v1 the API only grows; nothing your scripts use is renamed or removed.
Sign-in and five roles (Administrator, Operator, Joiner, Browse, PasswordSet) are enforced on the server for every call. Passwords are stored as strong one-way hashes, connector secrets are encrypted in the database, and every configuration change is audited with who, what, when, before and after.
Windows Server with install and upgrade scripts, Linux, or containers with Docker Compose, on x64 or ARM64. The whole configuration exports as readable JSON for Git and for moving between test and production. A correlation ID follows every request from the portal into the logs.
We are looking for pilot customers who run MIM Sync today. Bring your management agents and rules extensions, and we'll show you how they map, object by object.
