LIAM/Sonstiges/LIAM_NTFS_Massenverarbeitung_ADGruppen_Konzept.md

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.