LIAM/Sonstiges/LIAM_NTFS_Share_Provisionierung_und_ADGruppen_Konzept.md

LIAM NTFS Share-Provisionierung und AD-Gruppen - Konzept

Ziel

Dieses Dokument beschreibt ein Zielkonzept, um neue Benutzer analog zum bestehenden NTFS-Ordnerprinzip auch fuer Shares ueber AD-Gruppen zu berechtigen.

Betrachtet werden zwei Faelle:

1. komplette Neuanlage eines Shares
2. Erzeugung und Konfiguration passender AD-Gruppen fuer einen bereits bestehenden Share

Das Dokument ist bewusst ein Konzept. Es beschreibt Zielbild, notwendige Schritte, technische Erweiterungen und offene Entscheidungen, aber keine direkte Implementierung.

Ausgangslage im aktuellen Stand

Der aktuelle NTFS-Pfad deckt heute nur einen Teil des benoetigten Verhaltens ab:

• CreateDataAreaAsync(...) erzeugt nur Verzeichnisse und NTFS-ACLs fuer einen Ordnerpfad.
• EnsureMissingPermissionGroupsAsync(...) stellt fehlende AD-Gruppen und NTFS-ACLs fuer einen bestehenden Ordnerpfad sicher.
• cLiamNtfsShare existiert als DataArea-Typ, aber es gibt keinen eigenen Schreibpfad fuer die Share-Neuanlage.
• Die aktuelle Berechtigungslogik arbeitet technisch auf Dateisystempfaden und NTFS-ACLs.
• Eine echte SMB-Share-Erzeugung oder Pflege von Share-Berechtigungen ist derzeit nicht vorhanden.

Wichtig ist daher:

• Das bestehende Prinzip fuer Ordner kann teilweise wiederverwendet werden.
• Fuer Shares reicht eine reine Wiederverwendung des Ordnerpfads nicht aus.
• Es braucht zusaetzlich einen eigenen Share-Provisionierungspfad.

Fachliche Grundentscheidung

Bevor implementiert wird, sollte fachlich festgelegt werden, was "Share berechtigen" in LIAM genau bedeutet.

Es gibt zwei moegliche Zielbilder:

1. nur NTFS-Berechtigungen auf dem Share-Root-Ordner pflegen
2. NTFS-Berechtigungen auf dem Share-Root-Ordner und zusaetzlich echte SMB-Share-Berechtigungen pflegen

Empfehlung:

• Fuer ein wirklich analoges Share-Prinzip sollten beide Ebenen gepflegt werden.
• Nur NTFS zu pflegen waere technisch einfacher, bildet aber Share-Berechtigungen nur unvollstaendig ab.

Das Konzept unten geht deshalb vom vollstaendigen Zielbild aus:

• AD-Gruppen erzeugen oder wiederverwenden
• NTFS-ACL auf dem Share-Root sicherstellen
• SMB-Share anlegen oder aktualisieren
• SMB-Share-Berechtigungen auf dieselben Gruppen ausrichten

Zielbild Architektur

Empfohlen ist eine Trennung in zwei technische Ebenen:

1. Dateisystem-/AD-Ebene
2. Share-Ebene

Die Dateisystem-/AD-Ebene kann weitgehend auf dem bestehenden DataArea_FileSystem-Prinzip aufbauen.

Die Share-Ebene ist neu und sollte separat gekapselt werden, zum Beispiel als eigener Share-Provisionierer oder als Erweiterung von cNetworkConnection.

Grund:

• Share-Erzeugung und Share-Berechtigungen sind fachlich nicht dasselbe wie NTFS-ACLs.
• Sie brauchen andere API-Aufrufe, andere Fehlerbehandlung und andere Validierungen.

Fall 1: komplette Neuanlage eines Shares

Ziel

Ein neuer Share soll vollstaendig bereitgestellt werden:

• physischer Zielordner vorhanden
• AD-Gruppen vorhanden
• Benutzer und Gruppenmitgliedschaften gesetzt
• NTFS-ACLs auf dem Root-Ordner gesetzt
• SMB-Share publiziert
• SMB-Share-Berechtigungen gesetzt
• Ergebnis als LIAM-DataArea nutzbar

Zusaetzliche Eingaben

Fuer einen echten Share-Create reichen die bisherigen Ordnerparameter nicht aus. Noetig sind zusaetzlich mindestens:

• ServerName
• ShareName
• ShareLocalPath oder ein technisch gleichwertiger physischer Zielpfad auf dem Server
• optional ShareDescription
• optional Share-spezifische CustomTags
• Owner-/Read-/Write-SIDs analog zum bestehenden Ordnerpfad

Optional sinnvoll:

• gewuenschtes Caching-Verhalten des Shares
• Offline-Availability
• ABE oder weitere Share-Optionen
• explizite Strategie fuer Share-Permissions

Warum ein eigener Input noetig ist

Der heutige Ordner-Create-Pfad arbeitet auf einem existierenden UNC-/Dateisystempfad. Bei einem neuen Share existiert der veroeffentlichte UNC-Pfad aber noch nicht.

Deshalb muss die Share-Neuanlage mit einem physischen Serverpfad arbeiten und darf nicht nur von einem spaeteren UNC-Share-Namen ausgehen.

Ablauf

Schritt 1: Eingaben und Zielkonflikte validieren

Vor der eigentlichen Anlage muessen folgende Punkte geprueft werden:

• ist der Server erreichbar
• ist der physische Zielpfad zulaessig
• existiert der physische Zielordner bereits
• existiert bereits ein Share mit demselben Namen
• ist der Share-Name nach Windows-Regeln gueltig
• ist die Ziel-OU fuer AD-Gruppen erreichbar
• sind die benoetigten Naming-Conventions und Tags vollstaendig

Abbruchkriterien:

• doppelter Share-Name
• ungueltiger Server- oder Zielpfad
• fehlende Berechtigungen fuer Dateisystem, AD oder Share-Verwaltung

Schritt 2: Physisches Zielverzeichnis bereitstellen

Falls der Root-Ordner noch nicht existiert, muss er zuerst erstellt werden.

Wichtig:

• Das darf nicht ueber den spaeteren Share-UNC-Pfad geschehen.
• Es braucht einen Zugriff auf den physischen Serverpfad.

Technische Moeglichkeiten:

• Zugriff ueber administrative Shares wie \\server\\D$\\...
• serverseitige API oder PowerShell-Remoting
• anderer dedizierter Remote-Mechanismus

Empfehlung:

• Die Share-Provisionierung sollte den physischen Serverpfad explizit kennen.
• Die spaetere DataArea sollte daraus den veroeffentlichten UNC-Pfad ableiten.

Schritt 3: Soll-Gruppen fuer den Share berechnen

Fachlich analog zu Ordnern werden die erwarteten Gruppen berechnet:

• Owner
• Write
• Read
• optional Traverse, falls fuer Share-Roots gewuenscht
• bei AGDLP zusaetzlich Domain-Local-Gruppen

Hier sollte dieselbe Template- und Tag-Logik wie bei Ordnern wiederverwendet werden.

Wichtig ist aber die Namensbasis:

• Bei einem Share sollte die Namensbildung stabil am Share-Root ausgerichtet sein.
• Die Namensbasis darf nicht davon abhaengen, ob spaeter unterhalb des Shares weitere Ordner existieren.

Empfehlung:

• zusaetzliche Platzhalter wie SHARENAME, SHAREPATH, SHARESERVER
• klare Regel, ob die bestehende Ordner-Relative-Path-Logik unveraendert ausreicht oder erweitert werden muss

Schritt 4: AD-Gruppen erzeugen oder wiederverwenden

Der bestehende Ensure-Ansatz kann weitgehend uebernommen werden:

• exakten Gruppennamen pruefen
• bei nicht-striktem Modus vorhandene passende Gruppen ueber ACL-/Wildcard-Logik wiederverwenden
• fehlende Gruppen anlegen
• Benutzer und verschachtelte Gruppen setzen

Fuer Share-Create gilt fachlich dieselbe Reihenfolge wie bei Ordnern:

1. alle benoetigten Gruppen aufloesen oder erzeugen
2. Mitgliedschaften setzen
3. SIDs und DNs final einlesen

Schritt 5: NTFS-ACL auf dem Share-Root setzen

Auf dem physischen Root-Ordner werden die passenden NTFS-Berechtigungen gesetzt.

Empfohlen:

• dieselbe Rechteabbildung wie bei Ordnern
• dieselbe Logik fuer AGP oder AGDLP
• explizite ACL-Pruefung vor dem Schreiben
• Ergebnis mit addedAclEntries und skippedAclEntries differenziert zurueckgeben

Schritt 6: SMB-Share veroeffentlichen

Nach erfolgreicher Dateisystem- und Gruppenanlage wird der Share selbst angelegt.

Dafuer wird eine neue technische Faehigkeit benoetigt, zum Beispiel:

• CreateShare(server, shareName, localPath, description, ...)

Technisch denkbar:

• Win32 NetShareAdd
• PowerShell New-SmbShare
• WMI/CIM

Empfehlung:

• moeglichst eine native, klar kapselbare Server-API nutzen
• Fehlercodes aus der Share-Anlage explizit in ResultToken uebernehmen

Schritt 7: SMB-Share-Berechtigungen setzen

Nach der Share-Erzeugung muessen die Share-Berechtigungen mit den erzeugten oder wiederverwendeten AD-Gruppen synchronisiert werden.

Empfohlene fachliche Abbildung:

• Owner-Gruppe: Full Control oder ein explizit definierter administrativer Satz
• Write-Gruppe: Change
• Read-Gruppe: Read

Wichtig:

• Share-Rechte sind fachlich nicht identisch zu NTFS-Rechten.
• Die Mapping-Regeln muessen explizit definiert werden.

Schritt 8: Read-back und Rueckgabe

Am Ende sollte der neu angelegte Share nochmals eingelesen werden:

• existiert der Share wirklich
• zeigt er auf den erwarteten Zielpfad
• stimmen NTFS-ACL und Share-Permissions
• stimmen aufgeloeste AD-Gruppen

Das Ergebnis sollte danach als NtfsShare inklusive Gruppenreferenzen zurueckgegeben werden.

Fall 2: bestehender Share, aber fehlende AD-Gruppen

Ziel

Fuer einen bereits publizierten Share sollen fehlende Gruppen und Berechtigungen analog zum bestehenden Ordner-Ensure-Pfad nachgezogen werden.

Unterschied zum heutigen Ordner-Ensure

Der heutige EnsureMissingPermissionGroupsAsync(...) kann technisch gegen einen vorhandenen Root-Ordner laufen. Das reicht fuer Shares aber nur teilweise:

• NTFS-ACL am Share-Root kann damit sichergestellt werden
• die SMB-Share-Konfiguration selbst wird damit nicht gepflegt
• bestehende Share-Berechtigungen werden damit nicht ausgelesen oder korrigiert

Deshalb braucht es fuer Shares einen eigenen Ensure-Pfad.

Eingaben

Mindestens benoetigt werden:

• SharePath als veroeffentlichter UNC-Pfad
• alternativ ServerName + ShareName
• optional physischer Zielpfad, falls nicht sicher auslesbar
• Owner-/Read-/Write-SIDs
• optionale CustomTags

Ablauf

Schritt 1: Share aufloesen und klassifizieren

Der bestehende Share muss zunaechst technisch aufgeloest werden:

• existiert der Share
• auf welchem Server liegt er
• welcher physische Zielpfad ist hinterlegt
• ist er ein klassischer Share oder ein DFS-Link

Empfehlung:

• Nur klassische Shares im ersten Schritt unterstuetzen.
• DFS-Links spaeter separat betrachten, weil dort Share-Pfad und Zielpfad auseinanderlaufen koennen.

Schritt 2: Ist-Zustand laden

Fuer den bestehenden Share muessen drei Ist-Zustaende geladen werden:

• vorhandene AD-Gruppen
• vorhandene NTFS-ACL auf dem Root-Ordner
• vorhandene SMB-Share-Berechtigungen

Nur damit kann spaeter ein echtes Delta gebildet werden.

Schritt 3: Soll-Gruppen berechnen

Die Gruppen muessen fuer den Share auf dieselbe Weise berechnet werden wie bei der Neuanlage.

Dabei sollte dieselbe Namensbasis verwendet werden wie im Create-Pfad, damit Create und Ensure fachlich konsistent bleiben.

Schritt 4: Wiederverwendung oder Neuanlage von AD-Gruppen

Analog zum bestehenden Prinzip:

• exakten Namen pruefen
• bei nicht-striktem Modus vorhandene passende Gruppen wiederverwenden
• bei mehrdeutigen Treffern nicht still entscheiden
• fehlende Gruppen neu erzeugen

Empfehlung:

• die bisherige ForceStrictAdGroupNames-Logik fuer Shares unveraendert wiederverwenden
• Wiederverwendung gegen bestehende ACLs nur dann zulassen, wenn eindeutig und fachlich plausibel

Schritt 5: NTFS-ACL sicherstellen

Auf dem physischen Share-Root wird anschliessend die NTFS-ACL zum Sollzustand gebracht.

Dabei sollte dieselbe Logik wie im Ordner-Ensure verwendet werden:

• bereits vorhandene explizite Regel erkennen
• fehlende Regel setzen
• Ergebnismengen getrennt dokumentieren

Schritt 6: SMB-Share-Berechtigungen sicherstellen

Zusaetzlich muessen die Share-Berechtigungen ausgewertet und auf Soll gebracht werden.

Dabei sind dieselben Gruppen wie fuer die NTFS-Seite zu verwenden, aber mit einem expliziten Mapping auf Share-Rechte.

Empfehlung:

• Read-Gruppe -> Read
• Write-Gruppe -> Change
• Owner-Gruppe -> Full Control

Falls im Ist-Zustand breit vergebene Standardrechte vorhanden sind, muss fachlich entschieden werden:

• beibehalten und nur ergaenzen
• oder gezielt bereinigen und auf LIAM-Gruppen normieren

Schritt 7: Ergebnis und Warnungen

Der Ensure-Pfad fuer Shares sollte im Ergebnis klar trennen:

• neu angelegte Gruppen
• wiederverwendete Gruppen
• hinzugefuegte NTFS-ACLs
• uebersprungene NTFS-ACLs
• hinzugefuegte Share-Berechtigungen
• uebersprungene Share-Berechtigungen
• Warnungen bei Mehrdeutigkeiten, Altlasten oder nicht bereinigten Fremdeintraegen

Notwendige technische Erweiterungen

1. Workflow- und Runtime-Oberflaeche

Empfohlen sind zusaetzliche dedizierte Aufrufe:

• CreateNtfsShareAsync(...)
• EnsureNtfsSharePermissionGroupsAsync(...)

Die bestehenden Ordner-Methoden sollten nicht still auf Shares umgebogen werden, weil die benoetigten Inputs und Resultate fachlich anders sind.

2. Provider-Ebene

Im NTFS-Provider braucht es einen expliziten Share-Schreibpfad:

• Eingaben validieren
• physischen Zielpfad und publizierten Share koordinieren
• AD-/NTFS-Engine aufrufen
• Share-Erzeugung oder Share-Update ausfuehren

3. Engine fuer Share-Operationen

Empfohlen ist eine neue technische Komponente, zum Beispiel:

• ShareProvisioningEngine
• oder eine klar getrennte Erweiterung von cNetworkConnection

Noetige Faehigkeiten:

• ShareExists
• GetShareInfo
• CreateShare
• EnsureSharePermissions
• optional RemoveSharePermission

4. ResultToken erweitern

Fuer Shares braucht es zusaetzliche Ergebnisfelder, zum Beispiel:

• createdShares
• reusedShares
• addedShareAclEntries
• skippedShareAclEntries
• shareWarnings

Alternativ kann ein eigener spezialisierter ResultToken fuer Share-Operationen eingefuehrt werden.

5. Logging

Fuer spaetere Betriebsdiagnose sollten diese Punkte explizit geloggt werden:

• Server, Share-Name, physischer Zielpfad
• exakter Create- oder Ensure-Modus
• Quelle einer Gruppenwiederverwendung
• Ergebnis der Share-Erzeugung
• Ergebnis der Share-Permission-Sicherung
• klare Trennung zwischen NTFS-ACL und Share-ACL

Wichtige offene Entscheidungen

1. DFS-Unterstuetzung

Fuer einen ersten belastbaren Schritt sollte sich die Implementierung auf klassische Shares konzentrieren.

DFS-Links sind fachlich moeglich, aber deutlich komplexer:

• publizierter Pfad und physischer Zielpfad koennen auseinanderfallen
• Share- und DFS-Berechtigung sind nicht dasselbe
• die Zielserver koennen wechseln

Empfehlung:

• Phase 1 nur klassische Shares
• DFS spaeter bewusst als eigener Ausbau

2. Share-Permissions als Pflicht oder Optional

Wenn nur NTFS gesetzt wird, bleibt das Share-Modell unvollstaendig.

Empfehlung:

• Share-Permissions als Bestandteil des Zielbilds definieren
• optional ueber Flag abschaltbar machen, aber nicht dauerhaft weglassen

3. Namensbildung fuer Share-Roots

Es muss eindeutig festgelegt werden, worauf sich die Gruppennamen eines Shares beziehen:

• nur auf den Share-Namen
• auf den physischen Root-Pfad
• auf den publizierten UNC-Pfad

Empfehlung:

• Primaerschluessel fachlich am publizierten Share-Namen ausrichten
• physische Pfadbestandteile nur zusaetzlich als Tags oder Beschreibung verwenden

4. Altlasten bei bestehenden Shares

Bei bestehenden Shares koennen bereits andere Gruppen oder breite Standardrechte existieren.

Dafuer braucht es eine klare Strategie:

• nur ergaenzen
• normierend bereinigen
• oder nur warnen

Empfehlung:

• im ersten Schritt nur ergaenzen und warnen
• bereinigende Eingriffe erst in einem spaeteren expliziten Modus

Empfohlene Umsetzung in Phasen

Phase 1

• dedizierter Ensure-Pfad fuer bestehende klassische Shares
• AD-Gruppen sicherstellen
• NTFS-ACL auf Share-Root sicherstellen
• Share-Permissions lesen und setzen

Phase 2

• vollstaendiger Create-Pfad fuer klassische Shares
• physisches Root-Verzeichnis anlegen
• Share publizieren
• Share read-back und Ergebnisobjekt liefern

Phase 3

• DFS-Sonderfaelle
• bereinigender Modus fuer Altlasten
• Massenverarbeitung fuer viele Shares

Kurzfazit

Fuer Shares ist keine reine Kopie des bestehenden Ordnerpfads ausreichend.

Noetig ist:

• Wiederverwendung der vorhandenen AD-Gruppen- und NTFS-Logik
• plus ein neuer Share-spezifischer Schreibpfad
• plus eine klare fachliche Behandlung von SMB-Share-Berechtigungen

Der sinnvollste erste Schritt ist ein eigener Ensure-Pfad fuer bestehende klassische Shares. Danach kann die vollstaendige Share-Neuanlage auf derselben Logik aufbauen.