schalli
b6b964b69d
Am Active Directory wurde nichts veraendert; es wurde ausschliesslich gelesen. Die beiden verbliebenen Pruefpunkte liessen sich auf der Tessera-Seite ausloesen, weil der Sync nur vergleicht, was er gespeichert hat, mit dem, was im Verzeichnis steht — ob eine Abweichung aus einer AD-Aenderung stammt oder aus einem verfaelschten Group-Datensatz, kann er nicht unterscheiden. #4 / A1 (Umbenennung bricht die Bindung nicht): Gruppe Albphone_Technik_VT neu importiert, danach in der Datenbank Name und DN auf einen veralteten Stand gesetzt, objectGUID echt gelassen. Der Sync fand die Gruppe allein ueber den objectGUID und schrieb den AD-Namen zurueck — "1 umbenannt". Nicht gemessen, weil dafuer das Verzeichnis geaendert werden muesste: dass AD den objectGUID bei einer Umbenennung stabil haelt. Das ist zugesicherte AD-Eigenschaft und kein Tessera-Code; der Anteil, der schiefgehen konnte, ist gemessen. #6 / b (Amber-Zeile): dieselbe Gruppe zur Standardgruppe gemacht, dann ihren gespeicherten objectGUID ins Leere zeigen lassen. Ergebnis: "1 geloescht" plus die amber gefaerbte vierte Zeile "Standardgruppen-Markierung musste neu vergeben werden (1x)". Die Markierung wanderte vor der Loeschung zurueck — die Korrektheitszusage von D-06 haelt. Ledger: #4 und #6 auf fixed. Offen bleiben #12 (braucht ein echtes Exchange-Postfach), #14 und #15 (in dieser Sitzung neu gefunden). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FYZcd3SSmo14QTqWx2KKzU
171 lines
7.6 KiB
Markdown
171 lines
7.6 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: 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.
|