Files

T

schalli b6b964b69d test(ldap): WINDOWS #4 und #6 belegt und geschlossen — ohne Aenderung am AD

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

2026-09-07 15:12:00 +02:00

7.6 KiB

Raw Blame History

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.

7.6 KiB Raw Blame History Unescape Escape