Files

T

schalli a1a8b4fa7b 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

2026-09-07 14:49:07 +02:00

5.2 KiB

Raw Blame History

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.

5.2 KiB Raw Blame History