Secure, read-write access to Active Directory for AI agents and automation via HTTP API contract.
169
Synit ADProxy turns Active Directory changes into planned, reviewable, verified and auditable workflows.
Instead of allowing every HR system, IAM platform, service desk workflow, script or internal application to hold its own Active Directory credentials and implement its own LDAP logic, ADProxy provides one governed HTTP interface.
External systems submit JSON requests describing either:
ADProxy validates the request, reads the current directory state, builds an ordered execution plan, identifies risk and dependencies, and shows what would happen before the change is applied.
After approval, ADProxy executes the accepted plan, verifies the resulting Active Directory state and returns a structured journal.
For webhook and pipeline integrations, planning and execution can also be performed through a combined endpoint with idempotency protection and explicit outcome reporting.
ADProxy is not a raw LDAP wrapper. It is an operational control plane for systems that need Active Directory automation to behave like a reliable product interface.
Active Directory remains a critical dependency for employee lifecycle processes, application access, infrastructure management and service desk operations. Yet many organisations still automate it through isolated PowerShell scripts, embedded service accounts, direct LDAP integrations and manual administrative tools.
These approaches often work technically, but they create inconsistent operational controls.
One integration may validate input before writing. Another may retry blindly after a timeout. A third may have no durable journal. A fourth may perform several dependent changes without verifying whether the earlier operations succeeded.
ADProxy provides one consistent operating model for these workflows:
Plan. Review. Apply. Verify. Audit. Recover.
Before modifying Active Directory, ADProxy can inspect the live state, validate the intended operation, resolve targets, identify dependencies, calculate the required actions and return a reviewable plan.
That plan can include:
Only an authorised caller can apply the accepted plan.
During execution, ADProxy performs the ordered actions, verifies the final directory state and records structured outcome information. If the result cannot be verified conclusively, the service reports an uncertain state rather than presenting the operation as successfully completed.
“Active Directory automation should not force every connected system to become an LDAP expert. ADProxy gives those systems a governed service contract.”
ADProxy uses HTTP and JSON as its primary integration model.
This allows it to connect with:
Clients can use direct JSON mutation requests, declarative desired-state requests, JSON-RPC calls or reusable JSONata templates.
External workflow systems can submit JSON mutations directly to the ADProxy webhook API.
The webhook path uses the same planning, validation, execution and verification engine as the rest of the HTTP API. It does not bypass the control model.
A workflow can choose between:
The combined endpoint is particularly useful for webhook and pipeline scenarios where one authorised service owns the complete workflow.
This distinction allows external systems to respond differently to invalid input, partial execution, uncertain provider state and service-level failures.
Webhook and pipeline integrations must be able to retry requests without accidentally performing the same Active Directory change twice.
ADProxy supports an Idempotency-Key header for combined plan-and-apply requests.
When the same key and request body are repeated, ADProxy returns the original response. If the key is reused with a different body, the request is rejected as a conflict.
Plans are also identified by a content-based plan_id. This helps ensure that the plan being applied is the same plan that was previously reviewed.
Idempotency is designed for safe repetition of the same request. It is not a mechanism for forcing a new attempt after an uncertain result.
ADProxy supports two complementary request styles.
The client defines individual steps such as:
Dependencies can be declared explicitly or derived from references between operation results.
The client describes what a user, group or generic object should look like.
ADProxy reads the current directory state and derives the minimal changes needed to reconcile it with the requested state.
This model is useful when the caller cares about the final outcome rather than every LDAP operation required to reach it.
Repeated onboarding, offboarding and group-management processes can be represented as JSONata templates.
A template can be:
This allows connected systems to supply business variables without rebuilding the complete mutation payload for every request.
Many organisations have multiple independent paths into Active Directory:
Each implementation may handle validation, retries, risk, logging and failure differently.
ADProxy provides one consistent service boundary for those concerns.
Primary users include:
ADProxy can replace or reduce:
It does not replace Active Directory, identity governance, privileged access management, SIEM or business approval systems.
Yes.
ADProxy provides separate endpoints for:
Separating plan and apply is recommended when a human, approval engine or independent automation step must review the change.
Operation chaining lets one step reference the result of another step.
A workflow can, for example:
ADProxy adds the required dependency relationships so that producer operations run before consumers.
Synit AD Proxy is built and maintained by synit.io.
License: Synit Repository License Product and service information: Synit AD Proxy
Content type
Image
Digest
sha256:aab0a4d25…
Size
5.3 MB
Last updated
about 23 hours ago
docker pull synitio/ad-proxy