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: Umbenennung bricht die Bindung nicht — BELEGT

Am Verzeichnis wurde nichts veraendert — es wird ausschliesslich gelesen, und das bleibt so. Der Umbenennungsfall wurde stattdessen auf der Tessera-Seite hergestellt, was denselben Code-Pfad trifft: der Sync vergleicht, was er gespeichert hat, mit dem, was im Verzeichnis steht. Ob die Abweichung entstand, weil im AD umbenannt wurde oder weil der gespeicherte Stand veraltet ist, kann er nicht unterscheiden — er sieht in beiden Faellen exakt dasselbe.

Aufbau: Die AD-Gruppe Albphone_Technik_VT wurde neu importiert (objectGUID dc78643c57f513408dc74d5f2b4e35a1). Danach wurden in der Tessera-Datenbank Name und DN auf einen veralteten Stand gesetzt (Albphone_Technik_ALTNAME, DN entsprechend) — genau der Zustand, den eine Umbenennung im Verzeichnis hinterlaesst. Der objectGUID blieb echt.

Ergebnis des Sync-Laufs 15:07:54:

AD-Gruppen: 0 neu übernommen, 1 umbenannt, 0 gelöscht

Danach in der Datenbank:

Feld	vorher (verfaelscht)	nachher
name	Albphone_Technik_ALTNAME	Albphone_Technik_VT
ldapDn	CN=Albphone_Technik_ALTNAME,...	CN=Albphone_Technik_VT,OU=Verteiler,OU=CTL_Gruppen,DC=ctl,DC=local
ldapObjectGuid	dc78643c…	dc78643c… (unveraendert)

Bewertung: Weder Name noch DN passten noch — die Gruppe wurde trotzdem gefunden und der Name auf den Stand des Verzeichnisses zurueckgeschrieben. Damit ist belegt, was A1 absichern soll: eine Umbenennung im AD laesst Tessera die Gruppe nicht verlieren, und die Loeschsemantik D-05 greift in diesem Fall nicht faelschlich.

Beleg: uat-2026-09-07/windows4-a1-umbenennung-erkannt.png

Grenze der Aussage, ausdruecklich benannt: Nicht von uns gemessen ist, dass das Active Directory den objectGUID bei einer Umbenennung stabil haelt. Das ist eine zugesicherte Eigenschaft von AD (objectGUID ist unveraenderlich, im Gegensatz zu DN und sAMAccountName) und kein Tessera-Verhalten — und es zu messen wuerde eine Aenderung am Verzeichnis verlangen, die nicht stattfindet. Der Anteil, der in Tessera liegt und schiefgehen konnte, ist gemessen.

---

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 — BESTANDEN

Ebenfalls ohne jede Aenderung am Verzeichnis. Die importierte Gruppe Albphone_Technik_VT wurde in Tessera zur Standardgruppe gemacht; danach wurden ihr gespeicherter objectGUID und DN in der Tessera-Datenbank auf Werte gesetzt, die es im Verzeichnis nicht gibt (ffffffff…, CN=Existiert_Nicht,…). Fuer die Existenzpruefung ist das ununterscheidbar von einer Gruppe, die im AD geloescht wurde.

Ergebnis des Sync-Laufs 15:09:07:

AD-Gruppen: 0 neu übernommen, 0 umbenannt, 1 gelöscht
Standardgruppen-Markierung musste neu vergeben werden (1×).

Die vierte Zeile erscheint und ist amber gefaerbt — deutlich abgesetzt von den grauen Zahlenzeilen darueber und den roten Fehlerzeilen darunter.

Datenbankstand danach: Albphone_Technik_VT ist weg, die Standardmarkierung steht wieder bei Alle Benutzer, Claude_VT ist unberuehrt. Die Uebergabe der Markierung lief also vor der Loeschung — das ist die eigentliche Korrektheitszusage von D-06, und sie haelt.

Beleg: uat-2026-09-07/windows6b-amber-zeile.png

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

Am Active Directory wurde nichts veraendert. Alle Zugriffe waren lesend; der einzige Schreibversuch (eine Wegwerf-Gruppe anzulegen) wurde vom Verzeichnis abgelehnt und danach nicht wiederholt — das Dienstkonto darf nur lesen, und das ist so gewollt.

In Tessera ist der Ausgangszustand wiederhergestellt, groesstenteils von selbst:

• Die zum Test importierte Gruppe Albphone_Technik_VT hat sich im Verlauf von Teil (b) selbst entfernt — das war der Test.
• Die Standardmarkierung steht wieder bei Alle Benutzer.
• Claude_VT ist unveraendert (9 Mitglieder, kein interner Name).
• Modul Cert Manager ist wieder deaktiviert (0 aktive Module).

Nicht zurueckgesetzt, weil Folge der beauftragten Sync-Laeufe: die Benutzerzahl stieg von 405 auf 409 (vier zuvor nicht importierte AD-Konten), und die Zeitstempel der uebrigen 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.