tessera-ctl/.planning/phases/16-ad-gruppen-synchronisation/16-LIVETEST-2026-09-07.md

Live-Test gegen echtes AD — 2026-09-07

Durchgefuehrt auf alpha (https://alpha.tessera.ctl.de) gegen das echte Active Directory balios.ctl.local (172.16.0.11), Basis-DN DC=ctl,DC=local, Dienstkonto svc_tessera@ctl.local. Angemeldet als admin (SUPER_ADMIN).

Betrifft die Ledger-Punkte WINDOWS.md #4 (Annahmen A1/A2) und #6 (Sync-Durchlauf im Browser).

---

WINDOWS #4 — Annahme A2: byteweise Filter-Syntax — BELEGT

Gemessen mit einer read-only Sonde im API-Container, die den Produktionsweg nachvollzieht. Der erwartete DN stammt aus der Tessera-Datenbank, nicht aus derselben Hilfsfunktion, die den Filter baut — sonst waere die Messung tautologisch (siehe Anti-Pattern-Tabelle in STATE.md).

Referenzobjekt: Gruppe Claude_VT, gespeicherter objectGUID d11c8cea7d455f49a4919daee0039aa3.

Messung	Ergebnis
EqualityFilter ueber rohen Buffer (heutiger Produktionsweg)	1 Treffer — cn=Claude_VT, DN identisch mit dem in Tessera gespeicherten, zurueckgelesener objectGUID identisch mit dem gespeicherten
\xx-escapter Hex-String (frueherer, fehlerhafter Weg)	0 Treffer
Unabhaengiger Anker: base-Suche auf dem gespeicherten DN	1 Treffer, gleiche Gruppe, gleicher objectGUID

Bewertung: A2 ist gegen ein echtes Active Directory bestaetigt. Der heutige Weg findet das Objekt, der frueher verwendete findet es nicht — das ist genau der Fehler, der am 2026-08-11 mit d2019dc behoben wurde, hier noch einmal am echten Verzeichnis nachgemessen.

Zusaetzlicher Beleg aus dem echten Produktionspfad: Der Sync-Lauf um 14:42 meldete AD-Gruppen: 0 neu uebernommen, 0 umbenannt, 0 geloescht. Haette die Existenzpruefung die Gruppe nicht gefunden, waere Claude_VT als verschwunden behandelt und geloescht worden. Sie steht unveraendert mit 9 Mitgliedern da.

WINDOWS #4 — Annahme A1: objectGUID uebersteht Umbenennung — OFFEN

Nicht durch Tessera pruefbar: der Beleg verlangt, eine AD-Gruppe tatsaechlich umzubenennen und danach zu messen, dass der objectGUID gleich bleibt und Tessera den neuen Namen nachzieht.

Das Dienstkonto darf nicht schreiben. Gemessen am 2026-09-07 beim Versuch, eine Wegwerf-Gruppe anzulegen:

00000005: SecErr: DSID-03152E24, problem 4003 (INSUFF_ACCESS_RIGHTS), data 0

Das ist kein Mangel, sondern gewollt (Entscheidung des Users, 2026-09-07): Tessera liest aus dem Verzeichnis und schreibt ausschliesslich in die eigene Datenbank. Damit ist A1 dauerhaft nicht aus Tessera heraus belegbar — der Beleg braucht immer eine Handlung durch einen AD-Administrator, danach ist er messbar. Kein Grund, das Rechtekonzept zu aendern.

---

WINDOWS #6 — Sync-Durchlauf im Browser

Teil (a) — drei Zahlenzeilen — BESTANDEN

Sync ueber Jetzt synchronisieren ausgeloest (Lauf 2026-09-07 14:42:22). Alle drei Zahlenzeilen erscheinen:

Erstellt: 4, aktualisiert: 404, deaktiviert: 0
Gruppenmitgliedschaften: 0 hinzugefügt, 0 entfernt
AD-Gruppen: 0 neu übernommen, 0 umbenannt, 0 gelöscht

Beleg: uat-2026-09-07/windows6a-sync-zahlenzeilen.png

Nebenbefund: Unter den Zahlenzeilen stehen zehn Fehlerzeilen in roher Techniksprache. Als eigener Ledger-Punkt erfasst (WINDOWS.md #15).

Teil (b) — Amber-Zeile bei verschobener Standardmarkierung — OFFEN

Nicht ausloesbar ohne Schreibzugriff auf das Verzeichnis. Die vierte Zeile erscheint nur, wenn die Standardmarkierung vor einer Loeschung umgehaengt wird — das setzt voraus, dass eine AD-gebundene Gruppe im Verzeichnis tatsaechlich verschwindet.

Wichtig: das laesst sich nicht dadurch nachstellen, dass man die Gruppe aus dem konfigurierten Suchbereich nimmt. Genau dafuer hat der Code die WR-03-Weitsuche ueber die Domain-Wurzel: eine Gruppe, die nur ausserhalb des Basis-DN liegt, wird ausdruecklich nicht als geloescht behandelt. Das Verhalten ist korrekt und verhindert die Nachstellung.

Es gilt dasselbe wie fuer A1: das Dienstkonto darf nicht schreiben, und das ist gewollt. Der Beleg braucht eine Handlung durch einen AD-Administrator.

Gangbarer Weg ohne Risiko fuer echte Gruppen: der Administrator legt eine Wegwerf-Gruppe im AD an; sie wird in Tessera eingebunden und dort zur Standardgruppe gemacht; der Administrator loescht sie im AD; danach den Sync ausloesen und die Amber-Zeile pruefen. Dieselbe Wegwerf-Gruppe deckt mit einer Umbenennung zusaetzlich A1 ab.

Teil (c) — Spaltensuche unter beiden Namen — BESTANDEN

Vorbereitung: bei Claude_VT den internen Namen Vertrieb Team gesetzt. Die Gruppenliste zeigt danach den internen Namen, der AD-Name bleibt im gesperrten Namensfeld sichtbar.

Sucheingabe	Ergebnis
Vertrieb (interner Name)	Spalte Vertrieb Team bleibt stehen, Alle Benutzer wird ausgefiltert
Claude_VT (AD-Name)	Spalte Vertrieb Team bleibt ebenfalls stehen

Die Spalte ist also unter beiden Namen auffindbar — der Pruefpunkt ist erfuellt (grants/page.tsx:145 prueft internalName und name).

Dabei aufgefallen: Sobald die Suche greift, verschwindet die jeweils andere Achse vollstaendig, sodass kein Kaestchen mehr zum Klicken bleibt. Als eigener Ledger-Punkt erfasst (WINDOWS.md #14).

---

Zustand nach dem Test

Alles Veraenderte wurde zurueckgesetzt:

• Modul Cert Manager war zum Aufbau der Matrix voruebergehend aktiviert und ist wieder deaktiviert (0 aktive Module, wie vorher).
• Der interne Name Vertrieb Team wurde wieder geleert.

Nicht zurueckgesetzt, weil Folge des beauftragten Sync-Laufs: die Benutzerzahl stieg von 405 auf 409 (vier zuvor nicht importierte AD-Konten), und die Zeitstempel der bestehenden 404 Konten wurden aktualisiert. Reine Testdaten.

Der bestehende Haken Cert Manager fuer Alle Benutzer in der Matrix stammt nicht aus diesem Test: alle Gruppen-Freigaben tragen den Zeitstempel 2026-08-05 10:03:37. Der Aktivierungsdialog hat unter Spaeter konfigurieren korrekt keine Freigabe angelegt.