schalli
1e6999071e
Der Versuch, eine Wegwerf-Gruppe fuer den Livetest anzulegen, scheiterte mit INSUFF_ACCESS_RIGHTS. Das Dienstkonto svc_tessera darf am Verzeichnis nur lesen — vom User bestaetigt als gewollt, nicht als Luecke. Folge, jetzt an drei Stellen dokumentiert (Livetest-Bericht, Deferred Items, Ledger-Kontext): WINDOWS #4/A1 und #6b sind grundsaetzlich nicht aus Tessera heraus belegbar. Beide brauchen eine Handlung durch einen AD-Administrator; danach sind sie messbar. Kein Anlass, das Rechtekonzept zu aendern oder Schreibrechte zu erbitten. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FYZcd3SSmo14QTqWx2KKzU
135 lines
5.9 KiB
Markdown
135 lines
5.9 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 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.
|