# LIAM NTFS Massenverarbeitung / AD-Gruppenanlage - konkretes Konzept ## Ziel Dieses Dokument beschreibt ein konkretes Zielkonzept fuer die Verarbeitung grosser NTFS-Strukturen mit vielen Ordnern und automatischer AD-Gruppenanlage. Beispielgroessenordnung: - 1000 Ordner - pro Ordner 3 bis 6 Berechtigungsgruppen - optional Traverse-Gruppen Ziel ist eine fachlich korrekte, aber vor allem skalierbare Verarbeitung ohne unkontrolliert lange Laufzeiten. ## Problem des aktuellen Zustands Der aktuelle Code ist funktional auf einzelne Ordner oder kleine Mengen ausgerichtet. Bei grossen Strukturen ergeben sich mehrere Engpaesse: - Verarbeitung erfolgt pro Ordner sequentiell - pro Ordner werden Gruppen einzeln aufgeloest oder angelegt - bestehende Gruppen werden teilweise ueber OU-weite Wildcard-Suche gesucht - ACLs werden pro Ordner direkt gesetzt - Traverse-Verarbeitung enthaelt eine harte Wartezeit Damit ist die aktuelle Implementierung fuer Massenlaeufe fachlich nutzbar, aber technisch nicht belastbar. ## Ist-Zustand ### 1. Automatischer Ensure-Pfad bei `Get DataAreas` Wenn `EnsureNtfsPermissionGroups=true` gesetzt ist, wird fuer jede erkannte `cLiamNtfsFolder` nacheinander `EnsureMissingPermissionGroupsAsync(...)` aufgerufen. Das bedeutet: - jeder Ordner wird isoliert behandelt - keine gemeinsame Voranalyse - kein Caching ueber den gesamten Lauf ### 2. Create-/Ensure-Pfad Pro Ordner passiert derzeit im Wesentlichen: 1. Soll-Gruppen generieren 2. Benutzer-SIDs aufloesen 3. pro Gruppe in AD suchen 4. fehlende Gruppe anlegen 5. Mitglieder setzen 6. ACLs setzen 7. optional Traverse-Gruppen verarbeiten ### 3. Teure Stellen Die teuersten Einzelschritte sind aktuell: - OU-weite Wildcard-Suche in AD - mehrfaches Erzeugen und Pruefen von Gruppennamen bei Kollisionen - sequentielle LDAP-/AD-Zugriffe - sequentielle ACL-Updates - `Thread.Sleep(180000)` im Traverse-Pfad ## Skalierungsannahmen Grobe Groessenordnung fuer 1000 Ordner: - AGP: - 3 Gruppen pro Ordner - ca. 3000 Gruppenoperationen - AGDLP: - 6 Gruppen pro Ordner - ca. 6000 Gruppenoperationen Falls jeder Zugriff separat gegen AD und Dateisystem geht, ist die Gesamtlaufzeit nicht mehr akzeptabel. ## Zielbild Die Verarbeitung soll von einer ordnerweisen Online-Logik zu einem mehrstufigen Batch-Modell umgebaut werden. Empfohlenes Zielbild: 1. Struktur erfassen 2. Soll-Zustand fuer alle Ordner berechnen 3. Ist-Zustand aus AD und ACLs gesammelt laden 4. Delta bilden 5. Gruppen in kontrollierten Batches anlegen oder wiederverwenden 6. ACLs in kontrollierten Batches setzen 7. Traverse separat behandeln ## Grundprinzip Nicht pro Ordner sofort alles erledigen, sondern: - zuerst global analysieren - dann gesammelt abgleichen - dann nur das Delta ausfuehren Das reduziert: - LDAP-Calls - Share-/Dateisystemzugriffe - Redundanz - Gefahr von doppelten Gruppen ## Fachliche Verarbeitungsschritte ### Schritt 1: Ordnerliste erfassen Fuer den gewaehlten Root werden alle relevanten Ordner einmalig geladen. Ergebnis je Ordner: - technischer Pfad - Parent-Pfad - Tiefe - fachlicher Typ Wichtig: - dieser Schritt dient nur der Strukturerfassung - noch keine AD-Anlage ### Schritt 2: Soll-Gruppen fuer alle Ordner berechnen Fuer jeden Ordner werden die erwarteten Gruppen aus Naming Conventions und Tags berechnet. Ergebnis je Soll-Gruppe: - Ordnerpfad - Gruppe - Scope - AccessRole - exakter Soll-Name - Wildcard - benoetigte Mitglieder - benoetigte verschachtelte Gruppen Damit existiert ein kompletter Soll-Bestand fuer den gesamten Lauf. ### Schritt 3: AD-Ist-Zustand einmalig oder in grossen Batches laden Statt pro Gruppe die OU neu zu durchsuchen, wird die Ziel-OU gesammelt geladen. Empfohlene Daten: - `sAMAccountName` - `distinguishedName` - `objectSid` - `member` Die geladene OU wird in Dictionaries abgelegt: - nach `sAMAccountName` - optional nach Regex-relevanten Merkmalen Vorteil: - keine OU-Vollsuche pro Gruppe - kein O(n*m)-Verhalten bei vielen Gruppen ## Wichtige Optimierung Die aktuelle Wildcard-Suche darf im Batch-Pfad nicht mehr als LDAP-Vollscan pro Gruppe stattfinden. Stattdessen: - OU einmal lesen - lokal in Memory gegen Regex pruefen Das ist einer der wichtigsten Performance-Gewinne. ### Schritt 4: ACL-Ist-Zustand gesammelt erfassen Wenn bestehende ACL-Gruppen wiederverwendet werden sollen, werden die ACLs der Zielordner ebenfalls zuerst gesammelt gelesen. Ergebnis je Ordner: - direkt gesetzte ACL-Gruppen - gematchte Owner-/Write-/Read-/Traverse-Gruppen Dadurch kann die Wiederverwendung bestehender Gruppen lokal entschieden werden, ohne spaetere AD-Neuanlagen zu provozieren. ### Schritt 5: Delta bilden Fuer jede Soll-Gruppe wird entschieden: - exakter Treffer vorhanden - eindeutiger ACL-Treffer vorhanden - eindeutiger Regex-Treffer vorhanden - Gruppe fehlt und muss erzeugt werden Nur fuer fehlende Gruppen wird eine Anlage geplant. ### Schritt 6: Gruppenanlage in Batches Die Neuanlage sollte kontrolliert parallelisiert werden. Empfehlung: - kleiner, begrenzter Parallelitaetsgrad - z. B. 4 bis 8 parallele AD-Operationen Nicht empfohlen: - ungebremste Parallelisierung ueber Hunderte von Gruppen Grund: - AD, DCs und Netzwerk sollen nicht ueberlastet werden - Kollisionen und Transienten bleiben beherrschbar ### Schritt 7: Mitgliedschaften und Verschachtelung als eigener Schritt Gruppen anlegen und Mitglieder setzen sollten getrennt betrachtet werden. Empfohlene Reihenfolge: 1. alle fehlenden Gruppen erzeugen 2. SIDs/DNs refreshen 3. Mitglieder und Nested Groups setzen Das verhindert Folgefehler durch noch nicht existierende Gruppen. ### Schritt 8: ACLs in eigenem Batch-Schritt ACLs werden erst gesetzt, wenn die benoetigten Gruppen sicher existieren. Auch hier: - kontrollierte Parallelitaet - Fehler pro Ordner isolieren - Ergebnislisten sammeln ## Traverse-Gruppen Traverse muss aus dem normalen Massenpfad herausgezogen werden. Der aktuelle Ansatz mit harter Wartezeit ist fuer grosse Strukturen nicht tragbar. Fuer grosse Laeufe gilt: - Traverse standardmaessig deaktivieren oder separieren - Traverse als eigener Nachlauf - keine feste `Thread.Sleep`-Pause Stattdessen: - Polling oder Retry mit kleinem Intervall - nur fuer die konkret benoetigten Gruppen ## Neue logische Komponenten ### 1. `NtfsBulkPlanBuilder` Verantwortung: - Ordnerliste laden - Soll-Gruppen pro Ordner berechnen - Soll-ACLs vorbereiten ### 2. `AdSnapshotLoader` Verantwortung: - OU einmalig oder abschnittsweise laden - In-Memory-Index fuer: - `sAMAccountName` - `SID` - `DN` ### 3. `AclSnapshotLoader` Verantwortung: - direkte ACLs aller Zielordner einlesen - passende Berechtigungsgruppen markieren ### 4. `NtfsBulkDeltaResolver` Verantwortung: - Soll/Ist vergleichen - Wiederverwendung oder Neuanlage entscheiden ### 5. `AdBatchExecutor` Verantwortung: - Gruppenanlage - Mitglieder setzen - verschachtelte Gruppen setzen ### 6. `AclBatchExecutor` Verantwortung: - ACLs setzen - vorhandene ACLs erkennen - nur fehlende ACEs schreiben ## Empfohlenes Ausfuehrungsmodell ### Modus A: Analyse Nur ermitteln: - welche Gruppen fehlen - welche wiederverwendet wuerden - welche ACLs fehlen Ohne Schreibzugriffe. ### Modus B: Ensure Nur Delta anwenden: - fehlende Gruppen anlegen - fehlende Mitglieder ergaenzen - fehlende ACLs setzen ### Modus C: Traverse-Nachlauf Separat und optional: - Traverse-Gruppen erzeugen - Traverserechte setzen ## Fehlerstrategie Bei grossen Mengen darf ein Einzelfehler nicht immer den Gesamtjob abbrechen. Empfohlen: - Fehler pro Ordner oder Gruppe sammeln - Schwellenwert definieren - am Ende Gesamtstatus ableiten Beispiel: - `Success` - `SuccessWithWarnings` - `PartialFailure` - `Failure` ## Logging und Monitoring Bei grossen Laeufen werden strukturierte Fortschrittsdaten gebraucht. Empfohlene Kennzahlen: - Anzahl gescannter Ordner - Anzahl Soll-Gruppen - Anzahl wiederverwendeter Gruppen - Anzahl neu erzeugter Gruppen - Anzahl geaenderter Gruppenmitgliedschaften - Anzahl gesetzter ACLs - Anzahl uebersprungener ACLs - Anzahl Fehler - Laufzeit je Phase Wichtig: - Fortschritt nicht nur pro Objekt loggen - zusaetzlich Phasen- und Batch-Statistik loggen ## Konkrete technische Leitplanken ### Nicht mehr so - pro Ordner komplette OU-Wildcard-Suche - pro Gruppe sofortiger AD-Zugriff - Traverse mit fester 180-Sekunden-Wartezeit - keine Trennung zwischen Analyse und Ausfuehrung ### Stattdessen - OU-Snapshot einmalig laden - ACL-Snapshot gesammelt laden - Delta zentral berechnen - kontrollierte Parallelitaet - Traverse separat ## Rueckwaertskompatibilitaet Der bestehende Einzelordner-Pfad kann bestehen bleiben. Empfehlung: - bestehende Methoden fuer Einzelobjekte weiter nutzen - neuen Bulk-Pfad zusaetzlich einfuehren Beispiele: - `EnsureMissingPermissionGroupsAsync(...)` bleibt fuer Einzelordner - neuer Bulk-Einstieg fuer Listen oder Root-Strukturen ## Minimal sinnvolle erste Ausbaustufe Wenn nicht sofort das gesamte Zielbild umgesetzt werden soll, ist die sinnvollste erste Stufe: 1. OU nicht mehr pro Gruppe scannen, sondern einmalig laden 2. ACL-Wiederverwendung fuer alle Zielordner gesammelt vorbereiten 3. Traverse aus grossen Laeufen herausnehmen 4. Ensure fuer grosse Mengen explizit batchen Schon diese vier Punkte wuerden die groessten praktischen Probleme stark reduzieren. ## Entscheidung Fuer grosse Strukturen mit 1000+ Ordnern ist die aktuelle ordnerweise Online-Logik nicht ausreichend. Die empfohlene Zielumsetzung ist daher: - Batch-orientierte Voranalyse - AD-Snapshot statt OU-Scan pro Gruppe - ACL-Snapshot statt Einzelfallentscheidungen - Delta-basierte Ausfuehrung - kontrollierte Parallelisierung - Traverse als separater Spezialpfad Nur damit wird die AD-Gruppenanlage fuer grosse Strukturen technisch belastbar und operativ beherrschbar.