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