Every system a source. Every change a transaction.

Syntra is a synchronisation and automation platform. It reads the systems an organisation already runs - directories, databases, cloud platforms, ticketing, security tooling - keeps a queryable, audited copy of what it finds, transforms it, and moves changes back out through approval chains rather than through scripts. Identity and access is where it is strongest. The same pipeline carries configuration items, firewall rules, vulnerability findings and DNS records with the same discipline.

The conventional model: one suite per domain

An IAM suite holds the identities. A CMDB holds the assets. A security console holds the findings. Each one defines its own model, ships its own connectors, keeps its data in a store only its own console can read, and expects the organisation to reshape itself around the product. The estate ends up with three copies of the truth that never quite agree, and every cross-domain question - which admin can reach which server through which firewall rule - is answered by hand, or not at all.

The Syntra model: one pipeline over your own database

Syntra is a pipeline. A provider reads a system, a consumer writes one, and the core in between knows nothing about either. What lands in the middle is a plain SQL database with one table per entity, audit columns on every row, and the whole estate - identities, assets, rules, findings - open to T-SQL, Power BI, or any tool that speaks to SQL Server. Cross-domain questions become joins.

Four jobs, one pipeline

• Data synchronisation. Directory users and groups, cloud subscriptions and role assignments, service principals, CMDB records, mailboxes, repositories - streamed into per-entity tables, in full or as deltas, on a schedule.

• Data transformation and auditing. Shadow copies record what a source said at the time, so every transformation can be checked against its input. Near-live data feeds Power BI and reporting without touching the source systems.

• Security analysis. A directed graph of nodes and typed edges with confidentiality and availability factors that inherit along the graph. Lateral-movement paths across domains, firewall exposure and vulnerability reach become queries.

• Identity governance. Transaction-based change management: an operation, a predecessor chain, an approval request with a state machine, and a recorded result. Nothing reaches a target system without a row that says who asked, who approved and what happened.

Connector-agnostic by construction

Providers and consumers are plain .NET assemblies that implement two small interfaces. The core resolves them by name from configuration at run time, through reflection, and builds each one with the pieces it needs: its configuration, its logger, a decryptor for its credentials, and, for a provider, the metadata left behind by the previous run. Adding a system to Syntra means adding an assembly, not changing the core.

• A provider exposes one method: stream the entities it can see, with the properties asked for. It carries no knowledge of where they will go.

• A consumer exposes two: synchronise a provider's stream, then finalise. It carries no knowledge of where the stream came from.

• Every record is an IEntity: an identifier, a state (created, updated, deleted, unclassified) and a property bag. That is the whole contract between the two sides.

• Consumers that can write concurrently drive the stream in parallel, bounded by a configured degree of parallelism; consumers whose target needs ordered writes consume it sequentially. The provider does not change either way.

Sources today - identity: Active Directory, Entra ID, Exchange Online. Cloud and data: Azure Resources, Azure SQL and SQL Server, Oracle, Azure DevOps. Operations: ServiceNow, CMDB. Security: Tenable, Tufin, Infoblox, Ciphersuite.

Destinations today: SQL Server and Azure SQL, Active Directory, Schema Designer.

Full when it must be, delta when it can be

A full synchronisation streams everything a source holds, merges it into the destination, and then reconciles: rows the source no longer has are marked deleted, never dropped. A threshold caps how many rows one run may delete, so a source that comes back empty because of an outage does not empty the destination with it.

A delta synchronisation asks the source only for what changed since the last run. The mechanism is whatever the source itself offers, and the provider stores its own cursor as opaque metadata that the core hands back on the next run.

• Active Directory - update sequence number. A uSNChanged filter against the last USN seen.

• Entra ID and Exchange Online - delta token. The Microsoft Graph /delta endpoint.

• SQL Server and Oracle - timestamp. A modified-date predicate against the last run.

• ServiceNow and CMDB - timestamp. A REST date filter.

• Azure Resources - none. Full synchronisation on every run.

One table per entity. Every row accountable.

Synchronised data lands in per-entity tables whose shape the Schema Designer can infer from the source itself - point it at a new system and it proposes the table. The platform's own tables carry the S1 prefix and one shared discipline: a key, an identity, who inserted and updated each row and when, a soft-delete timestamp, and a row version for concurrency. Nothing is ever physically removed by a synchronisation.

• Identity and organisation. Identities modelled on SCIM, organisational units, roles and typed relationships between any two records - a person to a mailbox, a server to a firewall rule, a finding to an owner.

• Transactions and approvals. The change-management backbone: operations, predecessor chains, approval requests with a state machine, recorded results.

• Shadows. JSON copies of records as they were, so a transformation can be audited against what the source said at the time.

• Security graph. Nodes and typed edges with confidentiality and availability factors that inherit along the graph.

• Frontend metadata. Stored procedures describe their own fields, types, validation rules and menu structure, so a user interface is generated from the database rather than compiled against it.

Authorisation lives in the database, not in the API

The REST API is deliberately thin. It maps OData queries and HTTP verbs onto stored procedures, and it passes the caller's identity through to SQL Server rather than deciding anything itself. A request is authenticated with Windows Negotiate or a bearer token exchanged on the caller's behalf; the query then runs under that identity, and views and functions in the database decide which rows that person may see or change. The API cannot grant what the database would refuse - and a Power BI report or a T-SQL session gets exactly the same answer.

The same instinct applies to the moving parts around the core:

• Credentials are never plain text. Protected values in configuration are encrypted with Keyra, and are held in secure memory buffers once opened. Configuration files can live in source control.

• A connector loads only if it says what it is. The loader reads a file's manifest before loading it and admits only assemblies carrying the same strong-name identity as the core. A connector's Authenticode publisher is checked against the core's own and recorded on every load.

• Configuration decides what runs. A deployment enables only the connectors its configuration names, whatever else is on disk.

• Releases are signed off the network. Windows releases are Authenticode-signed with a hardware-held certificate; every archive is covered by a published checksum.

One core, four ways to run it

The synchronisation engine has no opinion about its host. The same core runs from a terminal, under a service manager, inside a container, or on a platform service; only the outer shell changes. Each release ships self-contained, so a target needs no .NET runtime installed, and nothing is trimmed, because connectors are resolved by name.

Windows Service

svcsyntra registers with the Service Control Manager, loads every configuration in its Configuration/ folder, and runs each on its own cron schedule. A lease file stops the same job running twice.

Linux daemon

The same executable, built for Linux, integrates with systemd as a Type=notify unit: readiness and shutdown are reported to the service manager, and logs go to the journal.

Docker

The self-contained Linux build runs as the container's entry point with Configuration/ mounted as a volume. The service manager integration stays inert outside systemd, so the process behaves as a plain long-running host under any orchestrator.

Azure App Service / Function App

The REST API is an ASP.NET Core application and deploys to App Service as one, with identity provided by Entra ID and the on-behalf-of exchange. The service host runs alongside it as a continuous WebJob when scheduling should live on the same platform.

Suites, scripts, and Syntra

One suite per domain: closed model, closed data

Each product owns its model and its connectors. Data is readable through that product's console and its reporting. Cross-domain questions are answered by hand, and extending anything means the vendor's SDK, the vendor's release cycle, and the vendor's licence.

• The organisation adapts to each product

• Three copies of the truth that never quite agree

• Workflow and audit locked inside each suite

Scheduled scripts: flexible, unaccountable

PowerShell and SQL jobs are quick to write and hard to govern. Credentials live in the script, deletions are whatever the script did last night, and the only audit trail is the scheduler's log.

• No shared entity model across scripts

• Full refresh every time, or bespoke delta logic

• No approval, no threshold, no shadow copy

Syntra: open pipeline, open data

• Connectors are assemblies; the model is your SQL database; changes are transactions with approvals. Identity, assets, rules and findings sit in one place, under one audit discipline. The core is Apache-2.0 and the data belongs to the tools you already use.

• Full and delta synchronisation from every connector

• Soft delete, thresholds, shadows and row-level audit

• Security graph and per-record authorisation enforced by the database

• Runs as a Windows Service, a Linux daemon, a Docker container, or on Azure App Service

Not another silo. Not a pile of scripts. A synchronisation platform you can query.

Syntra keeps the data of the estate where the organisation can reach it, and keeps every change to that estate accountable to a row someone can read.

Source on GitHub: https://github.com/PenguinConverters/Syntra

Syntra is licensed under Apache-2.0. The Keyra SDK is proprietary and separately licensed.