Add NTFS bulk AD group processing concept

This commit is contained in:
Meik
2026-03-13 23:25:59 +01:00
parent 9cfd266294
commit 865fa577e3

View File

@@ -0,0 +1,421 @@
# 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.