Synit ADProxy

Einführung

Synit ADProxy erklärt: Plan, Review, Apply, Verifikation, Audit, typische AD-Workflows, Rollout-Schritte und technischer Pilot für Enterprise Active Directory.

Einführung

Synit ADProxy ist ein kontrollierter Pfad für Änderungen in Enterprise Active Directory (AD). Statt Active-Directory-Schreiblogik in vielen Skripten, Workflow-Systemen oder Tools zu verteilen, laufen Änderungen über Plan, Review, Apply, Verifikation und Audit.

Das Ziel ist einfach: Bevor etwas in Active Directory geändert wird, soll klar sein, was passieren würde, wer es auslöst, welche Risiken markiert sind und wie das Ergebnis belegt wird.

Wofür ADProxy eingesetzt wird

  • Onboarding, Offboarding und wiederkehrende Lifecycle-Prozesse.
  • Gruppenmitgliedschaften, Zugriffsanfragen und Account-Operationen.
  • Strukturierte Änderungen an Active-Directory-Objekten.
  • HR-, ITSM-, IAM- und Plattformintegrationen.
  • Geprüfte Active-Directory-Automation mit Audit-Nachweis.

Verfügbarkeit und sicherer Start

Synit ADProxy ist als Container-basierte Laufzeit geplant. Eine freie Container-Variante ist für Evaluation, Laborumgebungen und kleine Piloten vorgesehen. Die konkrete Registry-URL, Funktionsgrenzen und Lizenzbedingungen werden in den Lizenzhinweisen ergänzt, sobald der öffentliche Lieferweg final ist.

Für produktive Active-Directory-Umgebungen sollte vorab geklärt werden, welche OU, Konten, Rechte, Audit-Ziele und Freigabeprozesse im Pilot erlaubt sind. Ohne Testlauf in einer passenden Test- oder Pilotumgebung gibt synit.io keine Zusicherung, dass Regeln, Pläne oder Integrationen für eine konkrete Active-Directory-Umgebung geeignet sind.

Plan, Review und Apply als Grundmodell

ADProxy arbeitet in zwei fachlich getrennten Phasen:

Plan: Request prüfen, aktuellen Active-Directory-Zustand lesen, Abhängigkeiten ordnen, Risiken markieren und einen Plan zurückgeben. Apply: freigegebenen Plan anwenden, Ergebnis prüfen und Journal erzeugen.

Ein Plan kann auch nur zur Prüfung erzeugt werden. Das ist der empfohlene Start für Pilotprojekte.

Geeignete erste Workflows

Gruppenmitgliedschaft

Ein Benutzer soll in eine Gruppe aufgenommen oder aus ihr entfernt werden. ADProxy prüft Gruppe und Mitglied, erkennt bereits erfüllte Zustände und verifiziert das Ergebnis nach Apply.

User Onboarding

Benutzer anlegen, Passwort setzen, Account-Einstellungen setzen, Gruppen ergänzen und Manager pflegen. Der Ablauf wird als ein zusammenhängender Plan sichtbar.

Offboarding

Konto deaktivieren, ausgewählte Gruppen entfernen, Objekt verschieben und Audit-Nachweis erzeugen.

Empfohlener Rollout im Pilot

  • Einen klaren ersten Workflow auswählen.
  • Pilot-OU oder Testobjekte festlegen.
  • LDAPS-Anbindung und Berechtigungen auf den Pilotumfang begrenzen.
  • Plan-only Requests erzeugen und gemeinsam prüfen.
  • Einen freigegebenen Plan in kleinem Umfang anwenden.
  • Audit, Ergebnis und mögliche Cleanup-Hinweise auswerten.
  • Erst danach weitere Workflows ergänzen.

Schnellstart für einen sicheren Pilot

Dieser Ablauf ist für einen kontrollierten ersten technischen Test gedacht. Starten Sie mit Container-Start, Konfigurationsprüfung, Readiness und read-only Abfragen. Plan-only kommt danach. Apply gehört erst in einen freigegebenen Pilot.

1. Werte vorbereiten

Klären Sie vor dem Start:

  • AD-Domain, zum Beispiel example.test
  • Domain Controller, zum Beispiel dc1.example.test
  • Pilot-OU, zum Beispiel OU=ADProxyPilot,DC=example,DC=test
  • Servicekonto mit minimal nötigen Rechten
  • read-only Token für Abfragen
  • read-write Token für Apply
  • Speicherort für Audit und Snapshot

2. Minimale Konfiguration anlegen

Erstellen Sie adproxy.hcl:

server {
  listen_addr = "0.0.0.0:8765"

  auth_token "pilot-reader" {
    secret = "<read-only-token>"
    access = "read-only"
  }

  auth_token "pilot-writer" {
    secret = "<read-write-token>"
    access = "read-write"
  }
}

directory {
  domain            = "example.test"
  bind_url          = "ldaps://dc1.example.test"
  bind_dn           = "CN=svc-adproxy,OU=Service Accounts,DC=example,DC=test"
  bind_password_ref = "env:AD_BIND_PASSWORD"
  hosts             = ["dc1.example.test"]
  timeout           = "30s"
}

query_policy {
  allowed_base_dns  = ["OU=ADProxyPilot,DC=example,DC=test"]
  allowed_attrs     = ["cn", "mail", "sAMAccountName", "memberOf"]
  denied_attrs      = ["unicodePwd", "ntSecurityDescriptor"]
  allow_raw_filters = false
}

audit {
  file_enabled = true
  file_path    = "/var/log/adproxy/audit-2006-01-02.jsonl"
}

snapshot {
  path     = "/var/lib/adproxy/snapshot"
  max_size = "256MiB"
}

3. Secret setzen und Konfiguration prüfen

export AD_BIND_PASSWORD='<ad-bind-password>'
docker run --rm \
  -e AD_BIND_PASSWORD \
  -v "$(pwd)/adproxy.hcl:/etc/adproxy/adproxy.hcl:ro" \
  <container-image> \
  adproxy-server validate-config -config /etc/adproxy/adproxy.hcl

4. Service starten

docker run --rm \
  -p 8765:8765 \
  -e AD_BIND_PASSWORD \
  -v "$(pwd)/adproxy.hcl:/etc/adproxy/adproxy.hcl:ro" \
  --name synit-adproxy \
  <container-image> \
  adproxy-server serve -config /etc/adproxy/adproxy.hcl

Prüfen Sie danach die Readiness:

curl -sS http://127.0.0.1:8765/readyz

5. Erste read-only Abfrage testen

curl -sS -X POST http://127.0.0.1:8765/api/v1/query \
  -u "pilot-reader:<read-only-token>" \
  -H "Content-Type: application/json" \
  -d '{
    "operation": "search_user_by_sam",
    "parameters": {
      "sam_account_name": "jdoe"
    }
  }'

6. Erste Änderung nur planen

curl -sS -X POST http://127.0.0.1:8765/api/v1/mutations/plan \
  -H "Authorization: Bearer pilot-writer:<read-write-token>" \
  -H "Content-Type: application/json" \
  -d '{
    "mutation_id": "pilot-add-group-member",
    "actor": "alice@example.test",
    "source": "pilot",
    "operations": [
      {
        "id": "add_member",
        "operation_type": "add_group_member",
        "target": {
          "dn": "CN=Pilot Group,OU=ADProxyPilot,DC=example,DC=test"
        },
        "object_class": "group",
        "member_dn": "CN=Jane Doe,OU=ADProxyPilot,DC=example,DC=test"
      }
    ]
  }'

Lesen Sie status, errors, warnings, plan_id und die geplanten Aktionen. Wenden Sie den Plan erst an, wenn Zielobjekte, Actor, Source und Risiko klar sind.

7. Freigegebenen Plan anwenden

Dieser Schritt darf erst nach fachlicher Prüfung, Pilotfreigabe und Backup-/Rollback-Klärung ausgeführt werden.

curl -sS -X POST http://127.0.0.1:8765/api/v1/mutations/apply \
  -H "Authorization: Bearer pilot-writer:<read-write-token>" \
  -H "Content-Type: application/json" \
  -d '{
    "plan_id": "<plan-id-aus-plan-response>",
    "actor": "alice@example.test"
  }'

Prüfen Sie danach Ergebnis, Audit-Datei und Active-Directory-Zustand. Bei rejected wurde nichts geschrieben. Bei uncertain ist eine manuelle Prüfung nötig.

Rollen, die früh eingebunden werden sollten

  • IAM Owner: verantwortet Lifecycle- und Access-Prozesse.
  • Active Directory Administrator: kennt OU-Struktur, Schema, Rechte und Betriebsvorgaben.
  • Plattformteam: betreibt ADProxy und integriert Upstream-Systeme.
  • Security oder Compliance: prüft Auth, TLS, Audit, Redaction und Freigaben.
  • Workflow Owner: bindet HR, ITSM, IAM oder interne Tools an.

Nächste Schritte in der Dokumentation

United in Diversity