Betrieb und Grenzen

ADProxy verbessert Kontrolle und Nachvollziehbarkeit von Änderungen in Enterprise Active Directory (AD). Es ersetzt aber nicht Active Directory, IAM-Governance, PAM, SIEM oder fachliche Freigaben.

Bausteine für den Betrieb

Typische Produktionsumgebungen berücksichtigen:

• LDAPS-Anbindung an Active Directory
• TLS am HTTP-Service
• getrennte Read-only- und Read-write-Zugänge
• Audit-Ausgabe als JSONL oder Syslog
• Redaction für sensible Werte
• Schema-Cache und Schema-Diagnostik
• Readiness Checks
• Snapshots und Journals für bessere Wiederaufnahme und Nachvollziehbarkeit

Audit

ADProxy schreibt strukturierte Ereignisse für geplante und angewendete Änderungen. Ein guter Upstream-Workflow speichert zusätzlich:

• plan_id
• Actor
• Quelle oder Ticketnummer
• Ergebnis
• Zeitfenster
• Audit-Referenz

So kann später nachvollzogen werden, welche Änderung geplant war, wer sie angestoßen hat und welches Ergebnis erreicht wurde.

Umgang mit generierten Secrets

Generierte Passwörter oder andere Secret Outputs werden nur im Apply-Ergebnis ausgegeben, wenn das explizit angefordert wurde. Sie sind später nicht über Query, Audit, Snapshot oder Mutation History abrufbar.

Behandeln Sie diese Werte wie Einmal-Secrets und übergeben Sie sie nur an freigegebene Zielsysteme.

Idempotenz und Wiederholungen

Für kombinierte Plan-and-Apply-Requests kann ein Idempotency-Key genutzt werden. Wiederholte Requests mit gleichem Key und gleichem Body liefern dasselbe Ergebnis zurück. Ein gleicher Key mit anderem Body wird abgelehnt.

Das schützt vor versehentlichen Doppel-Requests durch Workflow- oder Netzwerk-Retries.

Was ADProxy technisch absichert

• Plan beschreibt die beabsichtigte Änderung vor Apply.
• Apply prüft den Planbezug.
• Schritte werden in geordnete Gruppen gebracht.
• Riskante Operationen können explizite Freigabe erfordern.
• Nach Apply wird der Zielzustand geprüft.
• Journals machen Ergebnisse nachvollziehbar.
• Generierte Secrets werden nicht in Audit oder History gespeichert.

Was ADProxy bewusst nicht ersetzt

• Keine ACID-Transaktion über mehrere Active-Directory-Änderungen.
• Kein garantierter vollständiger Rollback.
• Keine globale Sperre gegen PowerShell, MMC, andere ADProxy-Prozesse oder andere Active-Directory-Writers.
• Keine spätere Wiederherstellung generierter Secrets.
• Kein Ersatz für fachliche Freigabeprozesse.

Praxis für einen belastbaren Betrieb

• Mit Plan-only starten.
• Pilotbereich klein halten.
• Read-only und Read-write Zugänge trennen.
• Freigabe für riskante Operationen explizit gestalten.
• Rejected und Uncertain Outcomes im Runbook erklären.
• Audit-Ausgabe regelmäßig prüfen.
• Active-Directory-Berechtigungen auf den benötigten Umfang begrenzen.