# 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.