---
phase: 16-ad-gruppen-synchronisation
kind: uat-nachtrag
date: 2026-09-07
windows_addressed: [5]
windows_still_open: [4, 6]
result: 1 bestanden, 2 weiterhin offen (echtes AD erforderlich)
---

# Phase 16 — Browser-Gegenprobe, nachgeholt am 2026-09-07

Von den drei offenen Punkten aus Phase 16 (WINDOWS.md #4, #5, #6) ließ sich einer
ohne erreichbares Active Directory nachholen. Die beiden anderen nicht — sie
messen den Sync selbst, nicht die Oberfläche.

**Aufbau:** frisch gebaute Images aus `main` (`79015dd`), lokaler Docker-Stack,
leere Datenbank, echter Chrome über Playwright.

## WINDOWS #5 — die drei Zustände des Gruppen-Dialogs (16-04) — BESTANDEN

| Zustand | Beobachtung |
|---|---|
| Anlegen | Kein Feld für eine AD-Bindung, sondern der Hinweis „AD-Gruppen werden im LDAP-Bereich importiert, nicht hier angelegt." mit Link „Zum LDAP-Bereich" |
| Lokale Gruppe umbenennen | Namensfeld frei editierbar, kein AD-Hinweis, kein Feld für einen internen Namen. Umbenennung von „Vertrieb" auf „Vertrieb Innendienst" zieht sofort in die Liste durch |
| Importierte Gruppe bearbeiten | Namensfeld **gesperrt** mit dem vollen AD-Namen und der Erklärung „Von der AD-Gruppe übernommen. Wird beim nächsten Sync automatisch aktualisiert."; darunter die Zeile „AD-DN: CN=Zentraler Einkauf,OU=Abteilungen,DC=firma,DC=local"; darunter das freie Feld „Interner Name" mit der Erklärung „Wird von der Synchronisation nie verändert. Bleibt das Feld leer, zeigt die Oberfläche stattdessen den AD-Namen." |

**Namensanzeige mit Tooltip nach dem Speichern:** Nach dem Setzen des internen
Namens auf „Einkauf Nordwest" zeigt die Liste diesen an, und das `title`-Attribut
der Namenszelle trägt den vollen AD-Namen „Abteilung Zentraler Einkauf und
Vergabemanagement Region Nordwest Standort Braunschweig". Die Spalte AD-Bindung
steht auf „AD-gebunden". Programmatisch aus dem gerenderten DOM ausgelesen, nicht
aus dem Quelltext geschlossen.

Beleg: `uat-2026-09-07/w5-gruppenliste-interner-name.png`

**Wie die importierte Gruppe entstanden ist — ausdrücklich vermerkt:** In dieser
Sandbox gibt es kein erreichbares Active Directory. Die AD-Bindung wurde deshalb
direkt in der Datenbank gesetzt (`ldapDn`, `ldapObjectGuid`, `internalName`), nicht
durch einen echten Import. Das ist für diesen Prüfpunkt zulässig, weil der zu
prüfende Dialogzustand ausschließlich vom Datensatz abhängt und nicht davon, wie er
entstanden ist. Für die Prüfpunkte #4 und #6 gilt das ausdrücklich **nicht** — die
messen den Sync-Vorgang selbst.

## WINDOWS #4 und #6 — weiterhin offen

Beide brauchen ein echtes Active Directory und können hier nicht ersetzt werden:

- **#4 (16-03):** Die Annahmen A1 (`objectGUID` übersteht eine Umbenennung im AD)
  und A2 (byteweise Hex-Filter-Syntax) sind gegen kein echtes Verzeichnis geprüft.
  Ein negatives Ergebnis bei A1 oder A2 wäre ein Stopp-Grund für die
  Löschsemantik (D-05). Der verwandte kritische Fehler in der Löscherkennung wurde
  am 2026-08-11 mit `d2019dc` behoben und dabei read-only am echten AD gemessen —
  A1 selbst bleibt davon unberührt offen.
- **#6 (16-05):** Einen Sync auslösen und die drei Zahlenzeilen sowie die
  Amber-Zeile bei verschobener Standardmarkierung prüfen. Ohne Verzeichnis gibt es
  keinen Lauf, dessen Zahlen man ablesen könnte. Die Spaltensuche der
  Freigaben-Matrix unter beiden Namen ist dagegen inzwischen indirekt belegt: die
  Matrix zeigt AD-gebundene Gruppen unter ihrem internen Namen an (siehe #5).

Beide Punkte bleiben im Ledger `open` und sind vor dem Produktivbetrieb der
AD-Synchronisation an einem echten Verzeichnis nachzuholen.