test(ldap): Live-Test gegen echtes AD — A2 belegt, zwei neue Defekte gefunden

Auf alpha gegen das echte Active Directory balios.ctl.local geprueft.

Belegt:
- WINDOWS #4 / Annahme A2 (byteweise Filter-Syntax): read-only gemessen.
  EqualityFilter ueber rohen Buffer findet Claude_VT (DN und objectGUID
  stimmen mit der Tessera-DB ueberein), der frueher verwendete escapte
  Hex-String findet nichts. Der erwartete DN stammt aus der Datenbank,
  nicht aus der Filter-Hilfsfunktion — sonst waere die Messung tautologisch.
- WINDOWS #6 Teil (a): Sync ausgeloest, alle drei Zahlenzeilen erscheinen.
- WINDOWS #6 Teil (c): die Spalte ist in der Freigaben-Matrix sowohl unter
  dem internen Namen als auch unter dem AD-Namen auffindbar.

Weiterhin offen, weil Schreibzugriff im Verzeichnis noetig:
- #4 / A1 (objectGUID uebersteht Umbenennung)
- #6 Teil (b) (Amber-Zeile bei verschobener Standardmarkierung). Ueber den
  konfigurierten Suchbereich nicht nachstellbar — die WR-03-Weitsuche
  verhindert das zu Recht.

Neu im Ledger:
- #14: Die Suche in der Freigaben-Matrix filtert beide Achsen mit demselben
  Begriff. Ein Begriff, der nur eine Achse trifft, leert die andere ganz —
  es bleibt nie ein Kaestchen zum Klicken. Damit scheitert genau der Zweck
  der Suche.
- #15: Der Sync reicht rohe Prisma-Fehler und englische Techniktexte an den
  Administrator durch. Vier AD-Konten aus OU=CTL_PWS_Gruppen werden wegen
  einer geteilten E-Mail-Adresse nie importiert, ohne verstaendlichen Hinweis.

Der Testzustand wurde zurueckgesetzt: Cert Manager wieder deaktiviert,
interner Name wieder geleert.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FYZcd3SSmo14QTqWx2KKzU

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

@@ -0,0 +1,119 @@
+# 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 pruefbar ohne Schreibzugriff auf das Verzeichnis: der Beleg verlangt, eine
+AD-Gruppe tatsaechlich umzubenennen und danach zu messen, dass der objectGUID
+gleich bleibt und Tessera den neuen Namen nachzieht. Der Stand vom 2026-08-11
+(kein AD-Schreibzugriff) wurde in dieser Sitzung nicht veraendert und nicht
+erneut geprueft — es wurde bewusst kein Schreibversuch gegen das
+Produktiv-Verzeichnis unternommen.
+
+---
+
+## 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.
+
+Gangbarer Weg ohne Risiko fuer echte Gruppen: eine Wegwerf-Gruppe im AD anlegen,
+in Tessera einbinden, dort zur Standardgruppe machen, dann im AD loeschen und
+den Sync ausloesen.
+
+### 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.