Plan
Der Plan-Endpunkt prüft Mutationen vorab, liest den aktuellen Active-Directory-Zustand, erkennt Abhängigkeiten und zeigt Risiken, bevor geschrieben wird.
Active Directory Control Plane
Active-Directory-Automation über HTTP, JSON und geprüfte Mutationen.
Synit ADProxy gibt IAM, Service Desk, HR-Systemen und Plattform-Automation einen gemeinsamen HTTP-Pfad für Enterprise Active Directory. JSON-Payloads, JSONata-Templates und Mutationen bilden ab, was erreicht werden soll: als Desired State oder als verkettete Operationen mit Plan, Apply, Verify und Audit.
ADProxy Datenfluss
Verlässliche System-Integrationen über gesicherte HTTP-Endpunkte.
User Intent
> Mutate: Add User to Group ...
AgentITSM / IDM / ScriptsSender
Plan APIMutation DraftEntwurf
ADProxy GuardPolicy & ApplyPrüfung
Active DirectoryLDAPS TargetZiel
Jede Änderung durchläuft ein striktes Plan-Apply-Verify-Audit Schema.
Modell
Ein API-Produkt für wiederkehrende AD-Workflows.
ADProxy ist kein roher LDAP-Wrapper. Der Service nutzt HTTP als Transport, JSON als Request-Modell und JSONata für wiederverwendbare Payload-Templates. Mutationen beschreiben entweder Zielzustände oder eine Kette aus ein bis mehreren Operationen. Der Plan/Apply-Kern prüft daraus, was passieren würde, bevor Änderungen an Active Directory gehen.
Apply
Der Apply-Endpunkt wendet einen geprüften Plan an. Danach verifiziert ADProxy das Ergebnis und schreibt Journal-Informationen für Betrieb und Audit.
Plan und Apply
Der kombinierte Endpunkt passt für Webhook- und Pipeline-Szenarien, wenn Planung, Prüfung, Ausführung und Journal in einem Schritt laufen sollen.
Warum ADProxy
Mehr Produktfähigkeit als einzelne Skripte, mehr Kontrolle als direkte Admin-Klicks.
ADProxy macht Active-Directory-Änderungen zu einem kontrollierbaren Service. Teams bekommen lesbare Payloads, planbare Änderungen, überprüfte Ausführung und strukturierte Nachweise. Das ist besonders wertvoll, wenn mehrere Systeme AD-Prozesse auslösen, aber nicht jedes System LDAP-Logik, Risikoentscheidungen und Recovery selbst lösen soll.
HTTP als einfache Integrationsbasis
ADProxy nutzt HTTP und JSON als Transport- und Payload-Modell. Dadurch können Service Desk, IAM, HR-Systeme, Plattform-Automation und Webhook-Pipelines denselben kontrollierten AD-Pfad nutzen.
Ein HTTP-Contract statt eigener Logik pro System.
JSON und JSONata für wiederkehrende Abläufe
Payloads bleiben maschinenlesbar und prüfbar. JSONata-Templates standardisieren Onboarding, Offboarding und Gruppenprozesse, ohne dass jedes angebundene System AD-Sonderfälle selbst modellieren muss.
Templates machen wiederkehrende Operationen reproduzierbar.
Desired State oder Operationskette
Mutationen können Zielzustände für Benutzer, Gruppen und Objekte beschreiben oder mehrere Operationen verketten. Spätere Schritte können Ergebnisse früherer Lookups oder Creates referenzieren.
Ein Request kann Zielzustand oder Ablaufkette ausdrücken.
Planung vor Risiko
Vor dem Schreiben entstehen logische Absicht, physische LDAP-Operationen, ausführbare Aktionen, Abhängigkeitsgruppen, Warnungen und ein stabiler Plan-Hash. So werden Änderungen vor der Freigabe greifbar.
Plan-only schafft prüfbare AD-Änderungen.
Durability für Webhook-Pipelines
Plan Store, Journals, Snapshots, Idempotency Keys und strukturierte Outcomes helfen, externe Pipelines wiederholbar zu machen. Unklare Ergebnisse werden nicht verschluckt, sondern sichtbar markiert.
Plan, Apply, Verify und Journal für robuste Automationen.
Read-only Kontext für bessere Requests
Query- und Schema-Endpunkte liefern Objekt- und Schema-Informationen, ohne zu schreiben. Integrationen können Benutzer, Gruppen, Attribute und erlaubte Operationen prüfen, bevor sie eine Mutation planen.
Read-only Query und Schema ergänzen den Mutation-Pfad.
Einsatzfelder
Für AD-Prozesse, die als Produkt-Schnittstelle funktionieren müssen.
Gute Startpunkte sind Prozesse mit klarer Struktur und messbarem Nutzen: Gruppenmitgliedschaften, Onboarding in einer Test-OU, Offboarding mit Review oder Webhook-Pipelines aus ITSM und IAM.
Onboarding
Benutzer anlegen, Passwort setzen, Gruppen ergänzen, Manager pflegen und den Endzustand prüfen.
Offboarding
Konten deaktivieren, Mitgliedschaften entfernen, Objekte verschieben und das Ergebnis dokumentieren.
Gruppen und Zugriff
Mitgliedschaften prüfen, No-ops erkennen und Änderungen nach Apply verifizieren.
Account-Operationen
Unlock, Passwort, Ablaufdatum, Smartcard- oder Delegation-Flags über einen geprüften Pfad ausführen.
Strukturelle Änderungen
Move, Rename und Delete mit Risikomarkern, Freigabe und Cleanup-Hinweisen behandeln.
Webhooks und Pipelines
HR-, ITSM- und IAM-Systeme über HTTP JSON, JSON-RPC, Webhooks oder JSONata-Templates anbinden.
Technische Fakten
Was Integrationen über die API bekommen.
ADProxy stellt schreibende und read-only Funktionen getrennt bereit. Mutationen laufen über Plan und Apply. Objekt- und Schema-Abfragen bleiben read-only und helfen Clients, gültige Requests zu bauen.
HTTP JSON API
Mutation, Query, Schema, JSON-RPC und Webhook-Pfade laufen über kontrollierbare HTTP-Endpunkte.
Plan/Apply-Endpunkte
Die Endpunkte für Plan, Apply und kombinierte Mutationen trennen Precheck, Ausführung und Pipeline-Nutzung.
JSONata-Templates
Templates rendern, planen oder starten wiederkehrende JSON-Mutationsflows für Onboarding, Offboarding und Gruppen.
Desired State
Desired Users, Desired Groups und Desired Objects beschreiben Zielzustände, die ADProxy gegen Live-AD diffen kann.
Operation Chaining
Operationen können Ergebnisse früherer Schritte referenzieren, etwa Distinguished Names aus Lookups oder Creates.
Read-only Query und Schema
Objektabfragen, Klassen- und Attribut-Metadaten helfen Clients, valide Requests ohne LDAP-Schreibzugriff zu bauen.
Durability und Audit
Plan Store, Idempotency Keys, Snapshots, JSONL Audit, Syslog und Journals unterstützen robuste Wiederholung und Nachvollziehbarkeit.
Betriebsgrenzen
TLS, Token-Modi, Readiness, Redaction, restricted operations und Force-Risk-Metadaten helfen, ADProxy sauber als Service zu betreiben.
Betrieb
Für den Betrieb als klare Servicegrenze gedacht.
ADProxy unterstützt LDAPS-Anbindung, HTTP TLS, Read-only- und Read-write-Zugänge, Schema-Diagnostik, Readiness Checks, Syslog, Redaction, Snapshots und Audit JSONL. Damit wird AD-Automation nicht nur ausführbar, sondern betreibbar.
Betriebsrahmen besprechenWichtig ehrlich zu benennen
- Kein ACID-Transaktionssystem; ADProxy arbeitet transaction-like mit Plan, Apply, Verify und Journal.
- Rollback ist best-effort, mit Hinweisen für manuelle Nacharbeit bei unklarem Zustand.
- Locks gelten im laufenden Prozess, nicht global gegen alle Active-Directory-Writers.
- MCP bleibt read-only; schreibende Änderungen laufen über ADProxy HTTP.