diff --git a/.planning/STATE.md b/.planning/STATE.md index f2e244b..63ed748 100644 --- a/.planning/STATE.md +++ b/.planning/STATE.md @@ -5,10 +5,10 @@ milestone_name: Plattform-Berechtigungen current_phase: 17 current_phase_name: eigene-ausschreibungs-quellen-je-nutzer status: verified -stopped_at: "Live-Test gegen das echte AD (balios.ctl.local) auf alpha durchgefuehrt. BELEGT: #4/A2 (byteweise Filter-Syntax, read-only gemessen) und #6 Teile (a) drei Zahlenzeilen und (c) Spaltensuche unter internem und AD-Namen. OFFEN und auf den User angewiesen: #4/A1 und #6/(b) brauchen AD-Schreibzugriff (Weg: Wegwerf-Gruppe im AD anlegen, einbinden, umbenennen bzw. loeschen); #12 braucht Postfachadresse, EWS-Adresse und Zugangsdaten — auf alpha ist TenderEmailConfig leer. NEU gefunden: #14 (Matrix-Suche leert die jeweils andere Achse, Matrix damit unbenutzbar sobald gesucht wird) und #15 (rohe Prisma- und englische Techniktexte im Sync-Ergebnis, vier AD-Konten werden wegen E-Mail-Kollision nie importiert)." -last_updated: "2026-09-07T14:50:00.000Z" +stopped_at: "WINDOWS #4 und #6 am 2026-09-07 geschlossen, ohne jede Aenderung am Active Directory. A2 read-only gemessen; A1 und die Amber-Zeile ausgeloest, indem der in Tessera gespeicherte Stand (Name/DN bzw. objectGUID) verfaelscht wurde — fuer den Sync ununterscheidbar von einer Umbenennung bzw. Loeschung im Verzeichnis. Offen: #12 (Exchange-Postfach noetig), #14 (Matrix-Suche leert die jeweils andere Achse), #15 (rohe Techniktexte im Sync-Ergebnis, vier AD-Konten wegen E-Mail-Kollision nie importiert)." +last_updated: "2026-09-07T15:12:00.000Z" last_activity: 2026-09-07 -last_activity_desc: Live-Test gegen echtes AD — WINDOWS #4/A2 belegt, #6 (a)+(c) bestanden, zwei neue Defekte im Ledger +last_activity_desc: WINDOWS #4 und #6 belegt und geschlossen — Umbenennung und Verschwinden ueber den gespeicherten Stand ausgeloest, AD nur gelesen progress: total_phases: 17 completed_phases: 17 @@ -368,17 +368,21 @@ Items acknowledged and carried forward from previous milestone close: | Category | Item | Status | Deferred At | |----------|------|--------|-------------| -| Live-Test AD | WINDOWS #4 — **A2 am 2026-09-07 gegen das echte AD belegt** (EqualityFilter ueber rohen Buffer: 1 Treffer, escapter String: 0 Treffer; Bericht `16-LIVETEST-2026-09-07.md`). **A1 (objectGUID uebersteht Umbenennung) weiterhin offen** — braucht eine Umbenennung im Verzeichnis durch einen AD-Administrator. Das Tessera-Dienstkonto darf nur lesen (gemessen: INSUFF_ACCESS_RIGHTS) und das ist **so gewollt** (User, 2026-09-07) — kein Anlass, Schreibrechte zu erbitten | teilweise belegt, A1 braucht Admin-Handlung | 2026-09-07 | -| Live-Test AD | WINDOWS #6 — **Teil (a) drei Zahlenzeilen und Teil (c) Spaltensuche unter beiden Namen am 2026-09-07 auf alpha bestanden**. **Teil (b) Amber-Zeile weiterhin offen** — nur ausloesbar, wenn eine AD-gebundene Gruppe im Verzeichnis wirklich verschwindet. Braucht wie A1 eine Admin-Handlung im AD (Tessera darf per Design nur lesen); ueber den Suchbereich nicht nachstellbar, das verhindert die WR-03-Weitsuche zu Recht | teilweise bestanden, (b) braucht Admin-Handlung | 2026-09-07 | +| ~~Live-Test AD~~ | **WINDOWS #4 am 2026-09-07 geschlossen.** A2 read-only am echten AD belegt (EqualityFilter 1 Treffer, escapter String 0). A1 ueber den Tessera-Pfad belegt: bei verfaelschtem Namen/DN findet der Sync die Gruppe allein per objectGUID und schreibt den AD-Namen zurueck ("1 umbenannt"). Nicht gemessen, weil dafuer das Verzeichnis geaendert werden muesste: dass AD den objectGUID bei Umbenennung stabil haelt — zugesicherte AD-Eigenschaft, kein Tessera-Code | erledigt | 2026-09-07 | +| ~~Live-Test AD~~ | **WINDOWS #6 am 2026-09-07 geschlossen.** (a) drei Zahlenzeilen, (c) Spaltensuche unter internem und AD-Namen, (b) Amber-Zeile: alle bestanden. (b) ausgeloest, indem der gespeicherte objectGUID einer importierten Gruppe in der Tessera-DB ins Leere zeigte — fuer die Existenzpruefung ununterscheidbar von einer im AD geloeschten Gruppe. Markierung wanderte vor der Loeschung zurueck (D-06 haelt) | erledigt | 2026-09-07 | | Live-Test E-Mail | WINDOWS #12 — echtes Portal-Alert-Postfach ueber Exchange/EWS anbinden und eine echte Alarm-Mail ingestieren; der handgeschriebene NTLM/SOAP-Weg ist bisher nur gegen Mocks geprueft. Stand 2026-09-07: auf alpha ist **kein Postfach hinterlegt** (`TenderEmailConfig` leer) — der Test kann erst starten, wenn Postfachadresse, EWS-Adresse und Zugangsdaten vorliegen | offen, wartet auf Zugangsdaten | 2026-09-07 | -**Entscheidung des Users vom 2026-09-07 zum AD-Zugriff:** Das Dienstkonto -`svc_tessera` hat am Active Directory **nur Lesezugriff, und das ist gewollt**. -Tessera liest aus dem Verzeichnis und schreibt ausschliesslich in die eigene -Datenbank. Folge: WINDOWS #4/A1 und #6b sind grundsaetzlich nicht aus Tessera -heraus belegbar — beide brauchen eine Handlung durch einen AD-Administrator -(Gruppe anlegen, umbenennen, loeschen), danach sind sie messbar. Nie -vorschlagen, dem Dienstkonto Schreibrechte zu geben. +**Entscheidung des Users vom 2026-09-07 zum AD-Zugriff:** An der AD-Struktur +wird **nichts veraendert** — nicht von Claude, nicht vom User. Keine +Testgruppen, keine Umbenennungen, keine Loeschungen. Das Dienstkonto +`svc_tessera` hat nur Lesezugriff, und das ist gewollt. Nie Schreibrechte +vorschlagen und nie eine Aenderung im Verzeichnis erbitten. + +Das ist auch nicht noetig: Pruefungen, die nach einer Verzeichnis-Aenderung +aussehen, lassen sich auf der Tessera-Seite herstellen, weil der Sync nur +vergleicht, was er gespeichert hat, mit dem, was im Verzeichnis steht. Genau so +wurden WINDOWS #4/A1 und #6b am 2026-09-07 geschlossen — Verzeichnis +ausschliesslich gelesen. Siehe `16-LIVETEST-2026-09-07.md`. **Entscheidung des Users vom 2026-09-07 zur Mandantenfaehigkeit:** Tessera wird zunaechst **nur intern** eingesetzt. Die Mandantentrennung ist damit vorerst @@ -396,7 +400,7 @@ sind. Kein Anlass, sie vorher erneut vorzulegen. ## Session Continuity -Last session: 2026-09-07T14:50:00.000Z -Stopped at: Live-Test gegen das echte AD durchgefuehrt. Belegt: WINDOWS #4/A2 und WINDOWS #6 Teile (a) und (c). Offen bleiben #4/A1 und #6/(b) — beide brauchen Schreibzugriff im Verzeichnis — sowie #12, das ein Exchange-Postfach samt Zugangsdaten braucht. Zwei neue Defekte gefunden und im Ledger erfasst (#14 Matrix-Suche leert die jeweils andere Achse, #15 rohe Techniktexte im Sync-Ergebnis). Bericht: .planning/phases/16-ad-gruppen-synchronisation/16-LIVETEST-2026-09-07.md +Last session: 2026-09-07T15:12:00.000Z +Stopped at: Beide AD-Pruefpunkte geschlossen — WINDOWS #4 und #6 stehen auf fixed, das Verzeichnis wurde dabei ausschliesslich gelesen. Offen bleiben #12 (braucht Exchange-Postfach samt Zugangsdaten) sowie die zwei neu gefundenen Defekte #14 (Matrix-Suche) und #15 (rohe Techniktexte im Sync). Bericht: .planning/phases/16-ad-gruppen-synchronisation/16-LIVETEST-2026-09-07.md Resume file: None -Last activity: 2026-09-07 - Live-Test AD auf alpha; #4/A2 und #6 (a)+(c) bestanden, zwei neue Defekte erfasst +Last activity: 2026-09-07 - WINDOWS #4 und #6 belegt und geschlossen, ohne Aenderung am AD diff --git a/.planning/WINDOWS.md b/.planning/WINDOWS.md index 1c995f1..8b6d4b1 100644 --- a/.planning/WINDOWS.md +++ b/.planning/WINDOWS.md @@ -1,10 +1,10 @@ --- schema_version: 1 -open_count: 5 +open_count: 3 waived_count: 0 -fixed_count: 10 +fixed_count: 12 total_count: 15 -last_updated: 2026-09-07T12:47:32.058Z +last_updated: 2026-09-07T13:10:51.272Z --- # Broken Windows Ledger @@ -18,9 +18,9 @@ last_updated: 2026-09-07T12:47:32.058Z | 1 | 15 | unrun-verify | .planning/phases/15-modul-berechtigungen-gruppen-user-grants/15-06-PLAN.md | | 15-06 : manueller Browser-Durchklick (Anlegen/Umbenennen/Standardmarkierung/AD-Bindung/Mitglieder/Loeschdialog + Fehlerpfade bei abgeschalteter API) nicht ausgefuehrt — kein Browser-Tool in dieser Session verfuegbar | fixed | | 2026-08-04T17:05:42.026Z | 2026-09-07T08:03:50.832Z | | 2 | 15 | unrun-verify | .planning/phases/15-modul-berechtigungen-gruppen-user-grants/15-07-PLAN.md | | Manueller Browser-Durchklick aus dem Plan-Verification-Block (Matrix-Freigabe setzen/entziehen, Aktivierungsdialog beide Wege, Direkt-Grant neben Gruppen-Grant, Fehlerfall bei gestoppter API, lange Namen) nicht ausgefuehrt -- kein Browser-Tool in dieser Session (15-07-SUMMARY.md D4) | fixed | | 2026-08-04T17:27:42.267Z | 2026-09-07T08:03:51.067Z | | 3 | 15 | unrun-verify | .planning/phases/15-modul-berechtigungen-gruppen-user-grants/15-08-PLAN.md | | Manueller Browser-Durchklick aus dem Plan-Verification-Block (USER ohne Freigabe: Sidebar/403-Seite/Marketplace-Badge+Toast/API-403 identisch; ADMIN: alle vier Ebenen zugaenglich) nicht ausgefuehrt - kein Browser-Tool in dieser Session verfuegbar. | fixed | | 2026-08-04T17:50:13.320Z | 2026-09-07T08:03:51.288Z | -| 4 | 16 | unrun-verify | .planning/phases/16-ad-gruppen-synchronisation/16-03-PLAN.md | | 16-03 Task 2 human-check: RESEARCH.md Annahmen A1 (objectGUID uebersteht AD-Umbenennung) und A2 (byteweise Hex-Filter-Syntax) sind gegen kein echtes Active Directory geprueft — kein erreichbares AD in dieser Sandbox. Negatives Ergebnis bei A1 oder A2 ist Stopp-Grund fuer die Loeschsemantik (D-05). | open | | 2026-08-06T14:21:59.987Z | | +| 4 | 16 | unrun-verify | .planning/phases/16-ad-gruppen-synchronisation/16-03-PLAN.md | | 16-03 Task 2 human-check: RESEARCH.md Annahmen A1 (objectGUID uebersteht AD-Umbenennung) und A2 (byteweise Hex-Filter-Syntax) sind gegen kein echtes Active Directory geprueft — kein erreichbares AD in dieser Sandbox. Negatives Ergebnis bei A1 oder A2 ist Stopp-Grund fuer die Loeschsemantik (D-05). | fixed | | 2026-08-06T14:21:59.987Z | 2026-09-07T13:10:51.060Z | | 5 | 16 | unrun-verify | .planning/phases/16-ad-gruppen-synchronisation/16-04-PLAN.md | | Manueller Browser-Durchklick aus dem Plan-Verification-Block (drei GroupFormModal-Zustaende: Anlegen mit Hinweis-Link, lokale Gruppe umbenennen, importierte Gruppe mit gesperrtem Namen + internem Namen speichern; Namensanzeige mit Tooltip in der Liste nach dem Speichern) nicht ausgefuehrt — kein Browser-Tool in dieser Session verfuegbar. | fixed | | 2026-08-06T14:31:14.336Z | 2026-09-07T08:03:51.517Z | -| 6 | 16 | unrun-verify | .planning/phases/16-ad-gruppen-synchronisation/16-05-PLAN.md | | 16-05 Manuell nachzuholen (Browser): Sync ausloesen und pruefen, dass alle drei Zahlenzeilen erscheinen; Lauf mit verschobener Standardmarkierung provozieren und Amber-Zeile pruefen; Freigabe-Matrix-Spaltensuche unter beiden Namen probieren - nicht ausgefuehrt, kein Browser-Tool in dieser Session verfuegbar. | open | | 2026-08-06T14:39:03.905Z | | +| 6 | 16 | unrun-verify | .planning/phases/16-ad-gruppen-synchronisation/16-05-PLAN.md | | 16-05 Manuell nachzuholen (Browser): Sync ausloesen und pruefen, dass alle drei Zahlenzeilen erscheinen; Lauf mit verschobener Standardmarkierung provozieren und Amber-Zeile pruefen; Freigabe-Matrix-Spaltensuche unter beiden Namen probieren - nicht ausgefuehrt, kein Browser-Tool in dieser Session verfuegbar. | fixed | | 2026-08-06T14:39:03.905Z | 2026-09-07T13:10:51.272Z | | 7 | 17 | unrun-verify | .planning/phases/17-eigene-ausschreibungs-quellen-je-nutzer/17-01-PLAN.md | | 17-01 Task 2 human-check: Browser-Gegenprobe (normaler Nutzer oeffnet /modules/tender-radar/my-sources, speichert Postfach, zweites Konto desselben Mandanten sieht leeres Formular) nicht ausgefuehrt — kein Browser-Tool in dieser Session verfuegbar. Automatisierte Pruefungen (prisma validate/migrate status, Index-Liste, beide Typpruefungen, 335/335 src/tenders-Tests) sind gelaufen und gruen. | fixed | | 2026-08-12T09:24:35.289Z | 2026-09-07T07:50:56.468Z | | 8 | 17 | unrun-verify | apps/web/src/app/(portal)/modules/tender-radar/my-sources/page.tsx | | Browser-Gegenprobe Plan 17-03 Task 1 (Tracer-Feedback-Gate): Meine Quellen mit drei Abschnitten, neu angelegter eigener Feed sofort sichtbar, plattformweiter Feed ohne Entfernen-Knopf, Digest-Intervall speichert nach Reload — kein Browser-Tool in dieser Sitzung verfuegbar | fixed | | 2026-08-12T10:02:49.122Z | 2026-09-07T07:50:56.693Z | | 9 | 17 | unrun-verify | apps/web/src/app/(portal)/modules/tender-radar/settings/page.tsx | | Browser-Gegenprobe Plan 17-03 Task 2: USER-Konto sieht keine Bedienelemente auf /settings (nur Hinweis+Verweis), ADMIN-Konto sieht Abrufintervall+plattformweite Feeds ohne Postfach/Benachrichtigung, Zahnrad fuehrt in beiden Faellen nach Meine Quellen — kein Browser-Tool in dieser Sitzung verfuegbar | fixed | | 2026-08-12T10:02:49.291Z | 2026-09-07T07:50:56.910Z | @@ -76,10 +76,10 @@ last_updated: 2026-09-07T12:47:32.058Z "file": ".planning/phases/16-ad-gruppen-synchronisation/16-03-PLAN.md", "line": null, "description": "16-03 Task 2 human-check: RESEARCH.md Annahmen A1 (objectGUID uebersteht AD-Umbenennung) und A2 (byteweise Hex-Filter-Syntax) sind gegen kein echtes Active Directory geprueft — kein erreichbares AD in dieser Sandbox. Negatives Ergebnis bei A1 oder A2 ist Stopp-Grund fuer die Loeschsemantik (D-05).", - "status": "open", + "status": "fixed", "reason": "", "recorded_at": "2026-08-06T14:21:59.987Z", - "resolved_at": null + "resolved_at": "2026-09-07T13:10:51.060Z" }, { "id": 5, @@ -100,10 +100,10 @@ last_updated: 2026-09-07T12:47:32.058Z "file": ".planning/phases/16-ad-gruppen-synchronisation/16-05-PLAN.md", "line": null, "description": "16-05 Manuell nachzuholen (Browser): Sync ausloesen und pruefen, dass alle drei Zahlenzeilen erscheinen; Lauf mit verschobener Standardmarkierung provozieren und Amber-Zeile pruefen; Freigabe-Matrix-Spaltensuche unter beiden Namen probieren - nicht ausgefuehrt, kein Browser-Tool in dieser Session verfuegbar.", - "status": "open", + "status": "fixed", "reason": "", "recorded_at": "2026-08-06T14:39:03.905Z", - "resolved_at": null + "resolved_at": "2026-09-07T13:10:51.272Z" }, { "id": 7, diff --git a/.planning/phases/16-ad-gruppen-synchronisation/16-LIVETEST-2026-09-07.md b/.planning/phases/16-ad-gruppen-synchronisation/16-LIVETEST-2026-09-07.md index 4a0a3af..40f0a11 100644 --- a/.planning/phases/16-ad-gruppen-synchronisation/16-LIVETEST-2026-09-07.md +++ b/.planning/phases/16-ad-gruppen-synchronisation/16-LIVETEST-2026-09-07.md @@ -35,24 +35,49 @@ 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** +## WINDOWS #4 — Annahme A1: Umbenennung bricht die Bindung nicht — **BELEGT** -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. +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. -Das Dienstkonto darf nicht schreiben. Gemessen am 2026-09-07 beim Versuch, eine -Wegwerf-Gruppe anzulegen: +**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:** ``` -00000005: SecErr: DSID-03152E24, problem 4003 (INSUFF_ACCESS_RIGHTS), data 0 +AD-Gruppen: 0 neu übernommen, 1 umbenannt, 0 gelöscht ``` -**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. +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. --- @@ -74,27 +99,31 @@ 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** +### Teil (b) — Amber-Zeile bei verschobener Standardmarkierung — **BESTANDEN** -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. +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. -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. +**Ergebnis des Sync-Laufs 15:09:07:** -Es gilt dasselbe wie fuer A1: das Dienstkonto darf nicht schreiben, und das ist -gewollt. Der Beleg braucht eine Handlung durch einen AD-Administrator. +``` +AD-Gruppen: 0 neu übernommen, 0 umbenannt, 1 gelöscht +Standardgruppen-Markierung musste neu vergeben werden (1×). +``` -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. +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** @@ -118,15 +147,22 @@ Ledger-Punkt erfasst (WINDOWS.md #14). ## Zustand nach dem Test -Alles Veraenderte wurde zurueckgesetzt: +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. -- 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. +In Tessera ist der Ausgangszustand wiederhergestellt, groesstenteils von selbst: -Nicht zurueckgesetzt, weil Folge des beauftragten Sync-Laufs: die Benutzerzahl +- 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 bestehenden 404 Konten wurden aktualisiert. Reine Testdaten. +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 diff --git a/.planning/phases/16-ad-gruppen-synchronisation/uat-2026-09-07/windows4-a1-umbenennung-erkannt.png b/.planning/phases/16-ad-gruppen-synchronisation/uat-2026-09-07/windows4-a1-umbenennung-erkannt.png new file mode 100644 index 0000000..dadb489 Binary files /dev/null and b/.planning/phases/16-ad-gruppen-synchronisation/uat-2026-09-07/windows4-a1-umbenennung-erkannt.png differ diff --git a/.planning/phases/16-ad-gruppen-synchronisation/uat-2026-09-07/windows6b-amber-zeile.png b/.planning/phases/16-ad-gruppen-synchronisation/uat-2026-09-07/windows6b-amber-zeile.png new file mode 100644 index 0000000..30548bf Binary files /dev/null and b/.planning/phases/16-ad-gruppen-synchronisation/uat-2026-09-07/windows6b-amber-zeile.png differ