schalli
a1a8b4fa7b
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
120 lines
5.2 KiB
Markdown
120 lines
5.2 KiB
Markdown
# 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.
|