Wie funktionieren NTFS-Berechtigungen und ACLs genau – inklusive Vererbung, Sonderfällen und effektiven Rechten?

Grundlagen der NTFS-ACL: Sicherheitsdeskriptor, DACL/SACL, ACE-Aufbau, SID-Prinzip und Auswertungsreihenfolge

Sicherheitsdeskriptor: Owner, Group, DACL, SACL und Kontrollflags

Jedes NTFS-Objekt (Datei, Ordner, benannter Stream) besitzt einen Sicherheitsdeskriptor, der die Sicherheitsattribute in einer fest definierten Struktur kapselt. Zentrale Bestandteile sind der Owner (Besitzer-SID), eine primäre Group-SID (historisch für POSIX-ähnliche Semantik, in Windows-Umgebungen meist ohne praktische Steuerungswirkung), die DACL (Discretionary ACL) zur Zugriffsentscheidung sowie die SACL (System ACL) für Auditing-Zwecke. Ergänzt wird dies durch Kontrollflags, die unter anderem festlegen, ob eine DACL/SACL vorhanden ist, ob sie “protected” ist (keine Vererbung) und ob ACEs bereits als geerbte Einträge markiert sind.

Die DACL ist für die Alltagsadministration maßgeblich: Sie enthält eine geordnete Liste von ACEs (Access Control Entries), die für bestimmte SIDs Rechte erlauben oder verweigern. Eine Besonderheit ist die “NULL DACL”: Ist im Sicherheitsdeskriptor keine DACL vorhanden, gilt das Objekt als für alle Zugriffe offen. Davon zu unterscheiden ist eine leere DACL, die vorhanden ist, aber keine ACEs enthält; sie führt faktisch zu “Zugriff für niemanden” (bis auf privilegierte Sonderpfade wie Backup/Restore-Rechte).

Die SACL steuert nicht den Zugriff, sondern protokolliert Zugriffsversuche anhand von Audit-ACEs. Das Setzen oder Auslesen der SACL erfordert typischerweise das Privileg SeSecurityPrivilege (z. B. “Manage auditing and security log”). In der Praxis beeinflusst die SACL daher eher Compliance- und Forensikprozesse als den operativen Berechtigungsvollzug.

DACL vs. SACL: Zweck, typische Inhalte und Abgrenzung

Die DACL beantwortet die Frage, ob ein Zugriff (z. B. Datei lesen, Ordner auflisten, Berechtigungen ändern) erlaubt ist. Die SACL beantwortet, ob ein Zugriff protokolliert werden soll, unabhängig davon, ob er erlaubt oder verweigert wird (je nach Audit-Konfiguration). Beide Listen sind ACE-basiert, nutzen aber unterschiedliche ACE-Typen und werden in getrennten Phasen ausgewertet.

• DACL (Zugriff): enthält “Allow”- und “Deny”-ACEs mit Zugriffsmaske; sichtbar und administrierbar z. B. mit icacls "C:\Pfad\Objekt" oder PowerShell Get-Acl -Path "C:\Pfad\Objekt".
• SACL (Auditing): enthält Audit-ACEs (Erfolg/Fehlschlag) und erfordert für Verwaltung häufig SeSecurityPrivilege; lesbar z. B. mit icacls "C:\Pfad\Objekt" /save acls.txt (je nach Kontext) oder über Sicherheits-UI mit “Überwachung”.
• Kontrollflags: bestimmen Vererbungsverhalten und Schutz, u. a. “DACL protected” (Vererbung blockiert) und Markierungen geerbter Einträge; in icacls spiegelt sich das über Vererbungszustände und Flags in den ACE-Anzeigen wider.

ACE-Aufbau: Typ, Flags, Zugriffsmaske, Objekt-GUIDs und SID

Ein ACE besteht konzeptionell aus ACE-Typ (z. B. “Access Allowed” oder “Access Denied”), ACE-Flags (z. B. Vererbung, nur-Vererbung, Vererbungsstatus), einer Access Mask (Bitmaske der Rechte), optionalen Objekt-spezifischen Feldern (Object ACEs) sowie der SID, auf die der Eintrag wirkt. Für NTFS-Dateisystemobjekte wird meist eine nicht-objektspezifische Maske verwendet; objektbezogene GUID-Felder sind stärker aus dem Verzeichnisdienst-Kontext (z. B. Active Directory) bekannt, kommen aber technisch auch in Windows-Sicherheitsdeskriptoren vor.

Die Access Mask ist das präziseste Element der Berechtigung: Sie kodiert einzelne Rechte (z. B. FILE_READ_DATA, FILE_WRITE_DATA, DELETE, READ_CONTROL, WRITE_DAC, WRITE_OWNER, SYNCHRONIZE). “Standardrechte” wie DELETE oder READ_CONTROL gelten objektartenübergreifend, während “spezifische Rechte” je nach Objekt (Datei vs. Verzeichnis) differieren. Diese Trennung ist relevant, weil grafische Dialoge häufig auf “Standardberechtigungen” und “Sonderberechtigungen” abbilden, intern jedoch eine einheitliche Bitmaske ausgewertet wird.

SID-Prinzip: Identitäten, Token und Auflösung von Gruppenmitgliedschaften

Windows bewertet NTFS-Rechte gegen SIDs, nicht gegen Namen. Ein Benutzername ist nur eine Anzeigeform, die per Lookup auf eine SID abgebildet wird. Der Zugriffstoken eines Prozesses enthält die Benutzer-SID, Gruppen-SIDs (inklusive verschachtelter Gruppen), Integritätslevel, Privilegien sowie Attribute wie “Deny-only” oder “Enabled”. Daraus folgt: Eine Berechtigung greift genau dann, wenn die ACE-SID im Token enthalten und das ACE nicht durch Tokenattribute deaktiviert ist.

Well-known SIDs (z. B. S-1-1-0 für “Everyone” oder S-1-5-32-544 für “Administrators”) verhalten sich stabil über Systeme hinweg, während Domänen-SIDs domänenspezifisch sind. Bei der Fehlersuche ist die SID-Darstellung oft präziser als die Namensansicht, insbesondere nach Umbenennungen, bei gelöschten Konten (verwaiste SIDs) oder bei Trust-Szenarien.

• SID-Auflösung (Beispiele): whoami /user
whoami /groups
wmic useraccount where name="Benutzer" get name,sid
• Token-Realität vs. Gruppenobjekt: Nur Gruppen-SIDs, die im Token als aktiv geführt werden, wirken in der DACL-Auswertung; in bestimmten Kontexten können Gruppen als “deny-only” markiert sein (z. B. bei UAC-Token-Splitting).
• Verwaiste SIDs: ACEs können SIDs enthalten, die nicht mehr auflösbar sind (gelöschte Konten). Die Zugriffsentscheidung bleibt formal möglich (SID-Vergleich), praktische Zuordnung und Pflege werden jedoch erschwert.

Auswertungsreihenfolge: Wie Windows DACLs tatsächlich entscheidet

Die Zugriffsprüfung erfolgt in Windows über einen Access-Check gegen den Zugriffstoken und die DACL. Praktisch relevant ist die kanonische Sortierung der DACL: Explizite Deny-ACEs stehen vor expliziten Allow-ACEs; danach folgen geerbte Deny-ACEs und geerbte Allow-ACEs. Innerhalb dieser Kategorien bleibt die Reihenfolge der ACEs relevant, insbesondere bei Mischungen aus Container-Only/Objekt-Only-Vererbungsflags und wenn Rechte nur teilweise gewährt werden sollen.

Deny wirkt nicht “global absolut”, sondern verweigert genau die in der Maske genannten Rechte, sofern die ACE auf die konkrete Objektart und den konkreten Zugriff passt. Enthält ein Token mehrere Gruppen-SIDs, können Allow-ACEs aus einer Gruppe durch Deny-ACEs einer anderen Gruppe für Teilrechte neutralisiert werden. Der resultierende effektive Zugriff entspricht der Menge der angefragten Rechte, die nach der ACE-Verarbeitung übrig bleibt. Dabei gilt: Wird ein Zugriff angefragt, prüft Windows die geforderten Bits; sind alle erforderlichen Bits erlaubt und keines davon durch einen passenden Deny blockiert, ist der Zugriff möglich.

Die Vererbung ist in diese Logik eingebettet, weil sie die DACL eines Unterobjekts um geerbte ACEs ergänzt. Für die Reihenfolge zählt jedoch nicht der Ursprung (Elternobjekt), sondern die Klassifizierung als explizit oder geerbt sowie die kanonische Sortierung. Administrationswerkzeuge können eine DACL beim Setzen in kanonische Form bringen; dadurch kann die sichtbare Reihenfolge von der Eingabereihenfolge abweichen, ohne die beabsichtigte Semantik zu verändern.

Rechtekatalog als Referenz: Standardrechte, erweiterte Berechtigungen, Objekt- vs. Containerrechte, Vererbungsflags und Bitmaskenwerte (tabelliert)

NTFS-Berechtigungen werden im Kern als Access Mask (Bitfeld) in einzelnen ACEs (Access Control Entries) einer DACL (Discretionary ACL) gespeichert. „Standardrechte“ sind dabei keine eigenen Bits, sondern vordefinierte Kombinationen aus erweiterten Rechten sowie Standard-/Generischen Rechten, die Windows in Dialogen und Tools bündelt. Für eine belastbare Analyse müssen drei Ebenen sauber getrennt werden: (1) welche Bits eine ACE setzt (Access Mask), (2) auf welche Objekte sie wirkt (Objekt/Container sowie Child-Typen) und (3) ob und wie sie vererbt wird (Inheritance/Propagation Flags). Die folgenden Tabellen dienen als Referenz zur Zuordnung dieser Ebenen.

Standardrechte (GUI) und typische Abbildung auf erweiterte Berechtigungen

Die üblichen Standardrechte, wie sie im Explorer („Sicherheit“) erscheinen, entsprechen typischen Bündeln aus erweiterten Berechtigungen. Je nach Objektklasse (Datei vs. Verzeichnis) unterscheidet sich insbesondere die Bedeutung von „Ordnerinhalt anzeigen“ gegenüber „Lesen & Ausführen“; beide basieren auf ähnlichen Kernrechten, werden aber im UI unterschiedlich benannt.

Erweiterte Berechtigungen: Objekt- vs. Containersemantik und Bitmaskenwerte

Die Access Mask verwendet fest definierte Bits. Mehrere Rechte teilen sich denselben Bitwert, unterscheiden sich aber durch Objektklasse: Auf Dateien bedeutet 0x00000001 „Daten lesen“, auf Verzeichnissen „Dateien auflisten“. Diese Doppeldeutigkeit ist beabsichtigt und wird in Windows als „File-System-Objektrechte“ kontextualisiert.

Generische Rechte und ihre kanonische Zuordnung

Generische Rechte (GENERIC_READ, GENERIC_WRITE, GENERIC_EXECUTE, GENERIC_ALL) werden nicht als solche „wirksam“, sondern vom Objektmanager auf objektspezifische Bits gemappt. In DACLs können sie dennoch als generische Bits gespeichert sein; viele Auswertungen (z. B. SDDL- oder API-Ausgaben) zeigen sie explizit. Für Dateisystemobjekte entspricht die Zuordnung einer etablierten Mapping-Tabelle, die im Ergebnis auf die in der vorherigen Tabelle genannten Bits führt.

Vererbungs- und Propagationsflags: Auswirkung auf Child-Objekte

Ob eine ACE an untergeordnete Objekte weitergegeben wird, steuern die Inheritance Flags. Zusätzlich beeinflussen Propagation Flags, ob die Vererbung „weiter nach unten“ reicht und ob eine ACE nur als vererbte ACE auf Children erscheint. Diese Mechanik wirkt unabhängig von der Access Mask; sie entscheidet ausschließlich über Reichweite und Platzierung der ACE.

• Nur Ordner, nicht Dateien (typisches „Ordner: Lesen“): Kombination CI ohne OI; in vielen UIs als „Dieser Ordner und Unterordner“ modelliert.
• Nur Dateien, nicht Ordner (typisches „Dateien erstellen/ändern“ ohne Ordnerrechte): Kombination OI ohne CI; praktisch relevant bei Drop-Zonen, wenn das Listen des Ordners getrennt behandelt wird.
• Nur vererben, nicht am Parent wirksam: IO wird fast immer zusammen mit CI und/oder OI genutzt, um das Parent-Objekt von der Wirkung auszunehmen, die Children aber gezielt zu belegen.
• Nur eine Ebene tief: NP begrenzt die Weitergabe; die ACE erscheint auf direkten Children als geerbte ACE, wird dort aber nicht weitergegeben.

Sonderfälle in der Rechtebenennung: „Unterordner und Dateien löschen“ vs. „Löschen“

Zwei häufig verwechselte Fälle hängen am Bit 0x00000040 (FILE_DELETE_CHILD) und am Standardrecht DELETE (0x00010000). DELETE erlaubt das Löschen des adressierten Objekts selbst (z. B. Datei oder Ordner, sofern keine anderen Sperren greifen). FILE_DELETE_CHILD wirkt nur auf Verzeichnisse und erlaubt das Löschen von untergeordneten Objekten innerhalb dieses Verzeichnisses, selbst wenn den Unterobjekten das Recht DELETE nicht explizit gewährt wurde. Dadurch entstehen Konstellationen, in denen das Löschen „von oben“ möglich ist, obwohl Unterobjekte restriktiver wirken.

Für Interpretationen auf ACE-Ebene gilt außerdem: „Verweigern“ (Deny) ist keine eigene Bitmaske, sondern ein ACE-Typ. Die Bitwerte bleiben identisch; ausschließlich die ACE-Art (ACCESS_DENIED_ACE_TYPE vs. ACCESS_ALLOWED_ACE_TYPE) entscheidet, ob Bits entzogen oder gewährt werden. Vererbung und Propagation wirken auf Allow- und Deny-ACEs gleichermaßen, was bei der Konstruktion „Deny nur auf Children“ (über IO) gezielt genutzt wird, aber in gemischten ACLs besonders sorgfältig geprüft werden muss.

Effektive Berechtigungen in der Praxis: Vererbungsrechnung, Konflikte durch Mehrfachmitgliedschaften und Deny, Sonderfälle (Creator Owner, Besitz/Take Ownership, Privilegien) sowie Freigabe- vs. NTFS-Rechte

Rechenlogik für effektive NTFS-Berechtigungen (DACL): Reihenfolge, Vererbung, Zusammenführung

Effektive Berechtigungen ergeben sich aus der DACL (Discretionary ACL) eines Objekts, den Sicherheitskennungen (SIDs) des Zugriffstokens (Benutzer, Gruppen, eingeschränkte SIDs) sowie dem angeforderten Zugriff (Desired Access). Die Auswertung erfolgt nicht als einfache „Summenbildung“ der Häkchen in der GUI, sondern als bitweise Prüfung gegen Access Masks, getrennt nach Allow– und Deny-ACEs, ergänzt um Spezialfälle wie CREATOR OWNER, Besitzrechte und Privilegien.

Für die Praxis ist entscheidend, dass explizite ACEs am Objekt andere Prioritäten haben als vererbte ACEs. Zudem kann ein Deny nicht „wegaddiert“ werden: Ein Deny auf die gleiche Maske dominiert unabhängig davon, wie viele Allow-Einträge vorhanden sind. Gleichzeitig gilt: Ein Deny, das nur ein Teilrecht betrifft (z. B. DELETE), blockiert nicht automatisch andere Teilrechte (z. B. READ_DATA), sofern der Zugriff nicht genau diese Bits benötigt.

• Token ermitteln: Mitgliedschaften und Privilegien des Zugriffstokens prüfen, z. B. whoami /groups
whoami /priv
• DACL am Zielobjekt lesen: ACEs inkl. Vererbungsflags und Masken sichtbar machen, z. B. icacls "D:\Daten\Projekt"
icacls "D:\Daten\Projekt" /save Acl.txt
• Explizit vor vererbt: Bei Konflikten zwischen gleichartigen Einträgen wirkt ein expliziter ACE am Objekt vor einem vererbten ACE derselben SID-Kombination; Deny bleibt dabei dominierend.
• Bitweise Auswertung: Der Zugriff ist nur dann vollständig erlaubt, wenn für alle angeforderten Bits kein wirksamer Deny greift und mindestens ein wirksamer Allow die Bits abdeckt; der Effekt ist daher abhängig vom konkreten Zugriffstyp (z. B. „Datei öffnen zum Lesen“ vs. „löschen“).

Konflikte durch Mehrfachmitgliedschaften und Deny: typische Muster und sichere Diagnose

Mehrfachmitgliedschaften führen regelmäßig zu unerwarteten Sperren, wenn breit vergebene Allow-Rechte durch einzelne Deny-ACEs punktuell ausgehebelt werden. Häufig entsteht der Deny nicht bewusst, sondern als Altlast aus früheren Berechtigungsmodellen („Deny für Praktikanten“) oder durch falsch platzierte Deny-ACEs auf Container-Ebene mit Vererbung auf Dateien. In Unternehmensumgebungen ist besonders riskant, Deny an große Sammelgruppen zu binden, weil die Deny-Wirkung dann auch Benutzer trifft, die über andere Gruppen legitime Rechte erhalten sollten.

Für belastbare Fehlersuche genügt die Explorer-Ansicht „Effektiver Zugriff“ allein oft nicht, da sie je nach Kontext nicht alle Zugriffsarten modelliert (z. B. Delete über Parent-Ordner). Eine praxistaugliche Diagnose kombiniert daher Token-Analyse (Gruppen), DACL-Auswertung (ACE-Reihenfolge/Vererbung) und konkrete Zugriffstests. Bei Dateisystemzugriffen über SMB kommen außerdem Freigaberechte und ggf. „Access-Based Enumeration“ als zusätzliche Einflussgrößen hinzu.

Vererbungsrechnung mit Beispiel: Container, Objekt, „Delete“ über Parent und zusammengesetzte Rechte

Ein häufiges Missverständnis betrifft Löschvorgänge: Das Löschen einer Datei benötigt nicht nur Dateirechte, sondern kann über den Parent-Ordner autorisiert werden. Unter NTFS ist dafür das Recht „Unterordner und Dateien löschen“ (Delete Child) am Container relevant. Dadurch kann eine Datei gelöscht werden, obwohl auf der Datei selbst kein DELETE-Allow gesetzt ist, sofern am Parent DELETE_CHILD erlaubt ist und kein Deny greift. Umgekehrt kann ein Deny auf dem Parent das Löschen verhindern, selbst wenn die Datei „Vollzugriff“ anzeigt.

Beispielszenario: Auf D:\Daten\Team gilt vererbt für Gruppe GG_Team „Ändern“. Zusätzlich existiert auf D:\Daten\Team\Archiv ein explizites Deny für GG_Team auf DELETE_CHILD, um das Entfernen von Dateien im Archiv zu unterbinden. Ein Benutzer ist Mitglied in GG_Team und in GG_ArchivAdmins, die explizit auf Archiv „Vollzugriff“ erhält. Ergebnis: Löschen scheitert trotzdem, wenn der Deny auf GG_Team die relevanten Bits trifft. Die zweite Gruppe addiert Allow, kann aber den Deny nicht neutralisieren. Abhilfe schafft nicht „mehr Allow“, sondern die Entfernung oder Umplatzierung des Deny (oder die gezielte Umgruppierung, sodass die Deny-SID nicht im Token enthalten ist).

• Parent-Ordner als Löschautorität prüfen: icacls "D:\Daten\Team\Archiv" und auf Einträge mit (DC) achten; Deny auf (DC) blockiert Deletes im Container unabhängig von Dateieinträgen.
• Datei vs. Ordner getrennt bewerten: Für eine Datei sind (OI)-vererbte ACEs relevant; für Unterordner (CI). Eine scheinbar „gleiche“ Berechtigung am Container muss nicht identisch auf Objekten ankommen.
• Überlappung der Masken konkret machen: Deny wirkt nur auf die betroffenen Bits; bei Fehlersuche den konkreten Vorgang abbilden (z. B. Öffnen zum Lesen, Schreiben, Umbenennen, Löschen) statt nur „Vollzugriff/Ändern“ zu vergleichen.

Sonderfälle: CREATOR OWNER, Besitz, Take Ownership und Privilegien (Backup/Restore)

CREATOR OWNER ist kein realer Benutzer, sondern ein Platzhalter, der bei der Vererbung durch den tatsächlichen Besitzer eines neu erstellten Objekts ersetzt wird. Das wird oft genutzt, um dem Ersteller Vollzugriff auf eigene Dateien zu geben, ohne individuelle Benutzer-ACEs zu pflegen. Wirkung und Risiko hängen am Besitz: Wechselt der Besitzer (z. B. durch administrative Übernahme), verschiebt sich damit auch die Reichweite dieser Rechte.

Besitz und Berechtigungen sind getrennt. Ein Besitzer darf die DACL ändern, auch wenn ihm sonst keine Zugriffsrechte eingeräumt wurden. „Take Ownership“ ist wiederum ein Recht, das in ACLs vergeben werden kann; daneben existieren Privilegien, die Zugriffskontrollen teilweise umgehen. Insbesondere SeBackupPrivilege und SeRestorePrivilege erlauben Sicherungs-/Wiederherstellungszugriffe in speziellen Modi, die die normale DACL-Prüfung nicht in gleicher Weise erzwingen. In der Praxis erklärt das, warum Backup-Software Dateien lesen kann, die für normale Benutzer gesperrt sind, ohne dass dafür zusätzliche Allow-ACEs gesetzt werden.

• Besitz sichtbar machen: Eigentümer auslesen, z. B. Get-Acl -LiteralPath "D:\Daten\Team\Archiv" | Select-Object -ExpandProperty Owner
• Privilegien als Ursache abklären: Bei Abweichungen zwischen „Test als Admin“ und „Test als Standardbenutzer“ Privilegien prüfen, z. B. whoami /priv; typische Kandidaten: SeBackupPrivilege, SeRestorePrivilege, SeTakeOwnershipPrivilege.
• CREATOR OWNER korrekt platzieren: Einsatz primär auf Container-ACEs mit Vererbung; der Platzhalter wird bei Erstellung in eine konkrete SID übersetzt und wirkt nicht als „Gruppenrecht“ für bestehende Objekte mit anderem Owner.

Freigabe- vs. NTFS-Rechte (SMB): effektiver Zugriff als Schnittmenge, plus Identitätskontext

Beim Zugriff über SMB gelten zwei Berechtigungsebenen: Freigaberechte am Share und NTFS-Rechte am Dateisystemobjekt. Effektiv wirksam ist die Schnittmenge beider Ebenen: Der Zugriff ist nur so weit möglich, wie ihn sowohl Share- als auch NTFS-Rechte zulassen. Ein Deny auf einer Ebene reicht aus, um den Zugriff für die betroffenen Bits zu blockieren. Deshalb führt ein „Everyone: Read“ am Share in Kombination mit „NTFS: Modify“ nicht zu Schreibzugriff, sondern zu effektivem Lesen.

Zusätzlich beeinflusst der Identitätskontext den Zugriff. Lokale Zugriffe verwenden den lokalen Token; SMB-Zugriffe laufen mit dem Netzwerk-Token und können durch Kerberos/NTLM, Delegation, „Double-Hop“-Grenzen und UAC-Remote-Restrictions in der Admin-Wirksamkeit abweichen. Für reproduzierbare Ergebnisse sollten Tests im gleichen Pfad (UNC vs. lokal) und mit gleicher Anmeldemethode erfolgen.