NTFS-Berechtigungen mit PowerShell auswerten – ohne Tool

Bevor du über ein Berechtigungsmanagement-Tool nachdenkst, brauchst du erst einmal Sicht auf den Ist-Zustand. Auf einem gewachsenen Fileserver weiß niemand mehr genau, wer wo direkt berechtigt ist, welche Konten längst gelöscht wurden und wo „Jeder" noch Vollzugriff hat. Die gute Nachricht: Für die Bestandsaufnahme reichen Bordmittel. Mit Get-Acl baust du in wenigen Minuten einen CSV-Report, der genau die drei Problemklassen sichtbar macht, die in jedem Audit auffallen.

Was Get-Acl liefert – und worauf es ankommt

Get-Acl gibt pro Objekt ein Security-Descriptor-Objekt zurück. Die eigentliche Berechtigungsliste steckt in der Eigenschaft .Access, einer Sammlung von FileSystemAccessRule-Einträgen (ACEs). Vier Felder sind für die Auswertung entscheidend:

• IdentityReference – das berechtigte Konto bzw. die Gruppe.
• FileSystemRights – die konkreten Rechte (z. B. Modify, FullControl).
• AccessControlType – Allow oder Deny.
• IsInherited – ob die Berechtigung geerbt (True) oder direkt am Objekt gesetzt (False) wurde.

Genau IsInherited ist der Hebel. In einer sauberen Struktur fließen Rechte von oben nach unten über Gruppen. Jede direkt gesetzte Berechtigung ist eine bewusste Ausnahme – oder ein Altlast-Verdacht.

Das Report-Skript

Das folgende Skript läuft einen Pfad bis zu einer wählbaren Tiefe ab, liest jede ACL und markiert die drei kritischen Muster: direkte Rechte, verwaiste SIDs und breite Sammelkonten.

# === NTFS-Berechtigungs-Report =====================================
$Root  = 'D:\Freigaben'                                   # Startpfad
$Depth = 2                                                # Unterordner-Tiefe
$Out   = 'C:\Reports\ntfs_report_{0:yyyyMMdd}.csv' -f (Get-Date)

# Breite Principals, die du im Report sehen willst (DE + EN)
$Broad = 'Jeder','Everyone','Authentifizierte Benutzer',
         'Authenticated Users','Benutzer','Users'

# Root + Unterordner bis zur gewünschten Tiefe einsammeln
$folders = @(Get-Item -LiteralPath $Root) + (
    Get-ChildItem -LiteralPath $Root -Directory -Recurse -Depth $Depth `
        -ErrorAction SilentlyContinue
)

$report = foreach ($f in $folders) {
    try   { $acl = Get-Acl -LiteralPath $f.FullName -ErrorAction Stop }
    catch { continue }                                    # z. B. Zugriff verweigert

    foreach ($ace in $acl.Access) {
        $id = $ace.IdentityReference.Value
        [pscustomobject]@{
            Pfad           = $f.FullName
            Konto          = $id
            Rechte         = $ace.FileSystemRights
            Typ            = $ace.AccessControlType        # Allow / Deny
            Direkt         = -not $ace.IsInherited         # True = direkt gesetzt
            VerwaisteSID   = $id -match '^S-1-'            # unaufgelöste SID
            BreiterZugriff = $Broad -contains ($id -replace '.*\\','')
        }
    }
}

$report | Sort-Object Pfad, Konto |
    Export-Csv -LiteralPath $Out -NoTypeInformation -Encoding UTF8

"Report geschrieben: $Out  ($($report.Count) Einträge)"
# ===================================================================

Öffne das CSV in Excel und filtere spaltenweise – jede der drei Markierungsspalten ist eine eigene To-do-Liste.

Die drei Befunde richtig lesen

1. Direkte Berechtigungen (Direkt = True)

Direkte ACLs umgehen dein Gruppenmodell und sind später kaum nachvollziehbar. Prüfe jede Ausnahme: Lässt sie sich durch eine Gruppenmitgliedschaft ersetzen? In den allermeisten Fällen: ja. Ziel ist, dass am Ende fast nur noch geerbte Rechte stehen.

2. Verwaiste SIDs (VerwaisteSID = True)

Wird ein AD-Konto gelöscht, kann Windows die SID im ACE nicht mehr in einen Namen auflösen – übrig bleibt eine Zeichenkette wie S-1-5-21-…. Solche Einträge sind toter Ballast, blähen die ACL auf und sind ein klassischer Audit-Fund. Vor dem Entfernen aber sauber dokumentieren.

3. Breite Sammelkonten (BreiterZugriff = True)

Jeder, Authentifizierte Benutzer oder Benutzer mit Schreib- oder Vollzugriff sind das Gegenteil von Least Privilege. Gerade auf höheren Freigabe-Ebenen gehören sie auf den Prüfstand und meist durch dedizierte Rollengruppen ersetzt.

Grenzen und Performance

Get-Acl ist bequem, aber auf sehr großen Strukturen langsam, weil pro Objekt ein vollständiger Security Descriptor geladen wird. Für Hunderttausende Ordner ist icacls <Pfad> /save zum Sichern bzw. die .NET-Methode GetAccessControl() deutlich schneller. Halte die -Depth zunächst niedrig und taste dich vor. Wichtig außerdem: Lauf das Skript mit ausreichenden Leserechten – fehlen sie, überspringt der catch-Block den Ordner stillschweigend.

Checkliste für den ersten Lauf

• Startpfad und Tiefe ($Depth) konservativ wählen
• Mit Konto laufen lassen, das alle Zielordner lesen darf
• CSV nach Direkt, VerwaisteSID, BreiterZugriff filtern
• Funde dokumentieren, bevor etwas geändert wird
• Änderungen erst im Test-/Freigabeverzeichnis erproben

Fazit

Mit knapp 30 Zeilen PowerShell verschaffst du dir eine belastbare Momentaufnahme deiner Fileserver-Berechtigungen – und triffst genau die drei Muster, die in jedem Berechtigungs-Audit zuerst auffallen. Das ist die Pflicht. Die Kür – kontinuierliche Überwachung, Rezertifizierung und Reporting auf Knopfdruck – übernehmen spezialisierte Lösungen; den Ist-Zustand für die Entscheidung lieferst du dir mit Bordmitteln selbst.

Mehr dazu: „NTFS vs. Freigabe-Berechtigungen: was wirklich greift" und „Verwaiste Berechtigungen aufspüren: der Cleanup-Leitfaden".

FAQ

Brauche ich Admin-Rechte für Get-Acl?

Zum Lesen reichen Leserechte auf die Ordner. Zum Ändern (Set-Acl) brauchst du Besitz oder das Recht „Berechtigungen ändern".

Warum sehe ich kryptische Zahlen statt Rechtenamen?

FileSystemRights kann numerische Werte enthalten, wenn generische Rechte gesetzt sind. Für den Report ist das unkritisch; relevant sind Konto, Direkt-Flag und Geltungsbereich.

---

Quellen (Recherche/Fakten): Microsoft Learn – Get-Acl / Set-Acl; Microsoft Learn (TechNet-Archiv) – Detect Users Who Have Direct Permissions on Your File Servers und Export Folder Permissions to CSV.
Hinweis: KI-gestützt erstellt, redaktionell geprüft.