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
Der Versuch, eine Wegwerf-Gruppe fuer den Livetest anzulegen, scheiterte mit
INSUFF_ACCESS_RIGHTS. Das Dienstkonto svc_tessera darf am Verzeichnis nur
lesen — vom User bestaetigt als gewollt, nicht als Luecke.
Folge, jetzt an drei Stellen dokumentiert (Livetest-Bericht, Deferred Items,
Ledger-Kontext): WINDOWS #4/A1 und #6b sind grundsaetzlich nicht aus Tessera
heraus belegbar. Beide brauchen eine Handlung durch einen AD-Administrator;
danach sind sie messbar. Kein Anlass, das Rechtekonzept zu aendern oder
Schreibrechte zu erbitten.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FYZcd3SSmo14QTqWx2KKzU
Auf alpha gegen das echte Active Directory balios.ctl.local geprueft.
Belegt:
- WINDOWS #4 / Annahme A2 (byteweise Filter-Syntax): read-only gemessen.
EqualityFilter ueber rohen Buffer findet Claude_VT (DN und objectGUID
stimmen mit der Tessera-DB ueberein), der frueher verwendete escapte
Hex-String findet nichts. Der erwartete DN stammt aus der Datenbank,
nicht aus der Filter-Hilfsfunktion — sonst waere die Messung tautologisch.
- WINDOWS #6 Teil (a): Sync ausgeloest, alle drei Zahlenzeilen erscheinen.
- WINDOWS #6 Teil (c): die Spalte ist in der Freigaben-Matrix sowohl unter
dem internen Namen als auch unter dem AD-Namen auffindbar.
Weiterhin offen, weil Schreibzugriff im Verzeichnis noetig:
- #4 / A1 (objectGUID uebersteht Umbenennung)
- #6 Teil (b) (Amber-Zeile bei verschobener Standardmarkierung). Ueber den
konfigurierten Suchbereich nicht nachstellbar — die WR-03-Weitsuche
verhindert das zu Recht.
Neu im Ledger:
- #14: Die Suche in der Freigaben-Matrix filtert beide Achsen mit demselben
Begriff. Ein Begriff, der nur eine Achse trifft, leert die andere ganz —
es bleibt nie ein Kaestchen zum Klicken. Damit scheitert genau der Zweck
der Suche.
- #15: Der Sync reicht rohe Prisma-Fehler und englische Techniktexte an den
Administrator durch. Vier AD-Konten aus OU=CTL_PWS_Gruppen werden wegen
einer geteilten E-Mail-Adresse nie importiert, ohne verstaendlichen Hinweis.
Der Testzustand wurde zurueckgesetzt: Cert Manager wieder deaktiviert,
interner Name wieder geleert.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FYZcd3SSmo14QTqWx2KKzU
schalli