Verwaiste SIDs und „Jeder“-Rechte auf Windows-Fileservern finden

Worum es geht: verwaiste SIDs, breite Gruppen, versteckte Ausnahmen

Windows speichert in den Zugriffslisten von Ordnern keine Namen, sondern Sicherheitskennungen (SIDs). Jedes Konto und jede Gruppe bekommt bei der Anlage eine eigene SID, und Windows vergibt sie nie ein zweites Mal – auch nicht an ein neues Konto mit demselben Namen. Wird ein Konto gelöscht, bleiben seine Einträge in den NTFS-Berechtigungen stehen. Windows findet dazu keinen Namen mehr und zeigt ein unbekanntes Konto mit der SID dahinter, etwa S-1-5-21-…-1107: eine verwaiste SID. Allerdings ist nicht jede SID ohne Namen verwaist – mehr dazu unter Nicht jede SID ohne Namen ist verwaist.

Breite Gruppen sind Gruppen, in denen praktisch alle stecken. Ihre SIDs stehen fest oder enden auf eine feste Zahl:

• „Jeder“: S-1-1-0 – alle Benutzer
• „Authentifizierte Benutzer“: S-1-5-11 – alle angemeldeten Benutzer und Computer, auch aus vertrauten Domänen
• „Domänen-Benutzer“: S-1-5-21-…-513 – jedes Benutzerkonto der Domäne; neue Konten kommen automatisch hinzu
• „VORDEFINIERT\Benutzer“: S-1-5-32-545 – enthält nach der Installation nur „Authentifizierte Benutzer“

Darf eine dieser Gruppen schreiben oder ändern oder hat sie Vollzugriff, kann praktisch jede angemeldete Person dort Dateien anlegen, ändern oder löschen – und mit ihr jede Schadsoftware, die unter ihrem Konto läuft. Zwei weitere Muster machen eine Prüfung schwer: Vererbung, die tief im Ordnerbaum unterbrochen ist – solche Ausnahmen sieht man von oben nicht –, und Rechte, die direkt an einzelne Personen statt an Gruppen vergeben sind. Microsoft empfiehlt, Zugriff über Gruppen zu vergeben: Wechselt jemand die Abteilung, ändert sich dann nur die Gruppenmitgliedschaft.

Typische Anlässe: Ein gewachsener Fileserver soll aufgeräumt oder umgezogen werden, oder eine Berechtigungsprüfung steht an – intern oder vor einem Audit, etwa nach ISO/IEC 27001.

Nicht jede SID ohne Namen ist verwaist

„Unbekannt“ heißt zunächst nur, dass Windows zu dieser SID gerade keinen Namen gefunden hat. Dafür gibt es Gründe, bei denen das Konto noch existiert oder gar kein Benutzerkonto ist:

• Funktions-SIDs (S-1-15-3-…)

  Seit Windows 8 und Windows Server 2012 gibt es SIDs für Funktionen (englisch Capabilities), über die Windows-Komponenten und Apps auf Ressourcen zugreifen. Sie haben absichtlich keinen Anzeigenamen. Microsoft rät ausdrücklich, sie nicht aus Datei- oder Registrierungsberechtigungen zu löschen: Funktionen können danach nicht mehr richtig arbeiten, und über die Oberfläche lassen sie sich nicht wieder eintragen. Die bekannten stehen unter HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SecurityManager\CapabilityClasses\AllCachedCapabilities.

• Domänencontroller nicht erreichbar

  Verhindert eine Zeitüberschreitung im Netz die Namenssuche, erscheint die SID ebenfalls ohne Namen – obwohl das Konto existiert.

• Konten aus anderen Domänen

  SIDs, die die eigene Domäne nicht kennt, sucht Windows in den vertrauten Domänen. Ist die Vertrauensstellung gestört oder die andere Domäne nicht erreichbar, bleibt der Name aus.

• Migrierte Konten

  Zieht ein Konto in eine andere Domäne um, bekommt es eine neue SID; die alte kann im SID-Verlauf (SIDHistory) des Kontos erhalten bleiben und gibt dann weiter Zugriff. Solche alten SIDs kann Windows in allen Domänen der Gesamtstruktur nachschlagen und zeigt dann den Namen des migrierten Kontos; ist die zuständige Domäne nicht erreichbar, bleibt der Name aus. Klären Sie deshalb vor dem Löschen einer SID aus einer früheren Domäne, ob ein migriertes Konto sie noch trägt – sonst nehmen Sie ihm Rechte.

• Anmeldesitzungen

  SIDs einer Anmeldesitzung (S-1-5-5-…) haben grundsätzlich keinen Kontonamen.

Echte verwaiste SIDs geben in der Regel niemandem mehr Zugriff, weil Windows keine SID neu vergibt. Ein Befund sind sie trotzdem: Niemand kann mehr sagen, wem das Recht einmal gegeben wurde. Riskanter als der Eintrag selbst ist das Löschen von Einträgen, die nur verwaist aussehen. Ein erster Anhaltspunkt ist der Domänenteil – alles vor der letzten Zahl einer SID wie S-1-5-21-…-1107. Mit einem Domänenkonto angemeldet, zeigt whoami /user Ihre eigene SID: Stimmt deren Domänenteil mit dem des unbekannten Eintrags überein, stammt er aus Ihrer Domäne.

Im Explorer: Sicherheit und „Effektiver Zugriff“

Für einen einzelnen Ordner genügen die Bordmittel. Eigenschaften › Sicherheit zeigt die NTFS-Berechtigungen, unter „Erweitert“ stehen die Einträge einzeln. Die Registerkarte „Effektiver Zugriff“ berechnet, was eine ausgewählte Person oder Gruppe an diesem Ordner darf; Rechte von „Jeder“ und „Authentifizierte Benutzer“ zählen dabei mit. Verwaiste SIDs erscheinen dort als SID ohne Namen – ob eine solche SID wirklich verwaist ist, klärt der Abschnitt Nicht jede SID ohne Namen ist verwaist.

Die Grenzen: Der Explorer zeigt einen Ordner und beim effektiven Zugriff eine Person auf einmal. Die Freigabeberechtigungen stehen getrennt unter „Freigabe“ › „Erweiterte Freigabe“. Eine Liste über den ganzen Ordnerbaum, einen Export oder einen Vergleich mit dem letzten Stand gibt es nicht. Für Stichproben reicht das, für einen gewachsenen Fileserver mit Tausenden Ordnern nicht.

icacls: den ganzen Ordnerbaum nach einer SID durchsuchen

icacls zeigt und ändert Zugriffslisten an der Eingabeaufforderung; icacls D:\Daten\Projekt zeigt die Liste eines Ordners. Für die Suche über einen ganzen Baum gibt es /findsid: Der Schalter findet alle Dateien und Ordner, deren Zugriffsliste die angegebene SID ausdrücklich nennt. Eine SID in Zahlenform bekommt ein * vorangestellt:

• icacls D:\Daten\* /findsid *S-1-1-0 /t /c – alle Dateien und Ordner unter D:\Daten, in deren Zugriffsliste „Jeder“ steht
• icacls D:\Daten\* /findsid *S-1-5-11 /t /c – dasselbe für „Authentifizierte Benutzer“
• icacls D:\Daten\* /findsid *S-1-5-21-…-1107 /t /c – wo eine bestimmte verwaiste SID noch eingetragen ist
• icacls D:\Daten\* /verify /t /c – Zugriffslisten, die nicht kanonisch sind

/t nimmt alle Unterordner mit, /c macht bei Fehlern wie „Zugriff verweigert“ weiter und zeigt sie trotzdem an. Kanonisch heißt: ausdrückliche Verweigerungen vor ausdrücklichen Erlaubnissen, danach die geerbten Einträge – in anderer Reihenfolge kann Windows anderes gewähren, als die Einträge auf den ersten Blick versprechen.

Die Grenzen: /findsid meldet, wo eine SID vorkommt, nicht welches Recht sie dort hat; ob „Jeder“ nur lesen oder auch schreiben darf, zeigt erst die Liste des einzelnen Ordners. Nach verwaisten SIDs allgemein kann icacls nicht suchen, nur nach einer SID, die Sie schon kennen. Gruppenmitgliedschaften und Freigabeberechtigungen kennt icacls nicht, und auf großen Freigaben kann die Suche lange dauern.

PowerShell: alle Einträge als Liste für Excel

Eine vollständige Liste, die sich in Excel filtern lässt, liefert ein kurzes PowerShell-Skript. Ein Beispiel für Windows PowerShell 5.1, das für jeden Unterordner von D:\Daten jeden Eintrag als Zeile in eine CSV-Datei schreibt:

Get-ChildItem -LiteralPath D:\Daten -Directory -Recurse | ForEach-Object { $p = $_.FullName; (Get-Acl -LiteralPath $p).Access | Select-Object @{Name="Pfad";Expression={$p}}, IdentityReference, FileSystemRights, AccessControlType, IsInherited } | Export-Csv D:\Bericht\rechte.csv -NoTypeInformation -Encoding UTF8 -UseCulture

-Encoding UTF8 erhält Umlaute in Pfaden und Namen – Windows PowerShell 5.1 schreibt sonst ASCII –, -UseCulture trennt die Spalten mit dem Listentrennzeichen der Ländereinstellung. In Excel filtern Sie dann IdentityReference nach den breiten Gruppen und FileSystemRights nach Werten wie FullControl, Modify oder Write. Einträge, die mit S-1-5-21-… statt mit einem Namen dastehen, sind Kandidaten für verwaiste SIDs; IsInherited trennt eigene von geerbten Einträgen. Den Startordner selbst prüfen Sie mit (Get-Acl -LiteralPath D:\Daten).Access.

Unterbrochene Vererbung zeigt die Eigenschaft AreAccessRulesProtected: Sie ist True, wenn ein Ordner keine Rechte vom übergeordneten Ordner übernimmt. Alle solchen Ordner listet Get-ChildItem -LiteralPath D:\Daten -Directory -Recurse | Where-Object { (Get-Acl -LiteralPath $_.FullName).AreAccessRulesProtected } | Select-Object FullName. Die Berechtigungen einer Freigabe liest Get-SmbShareAccess -Name Daten -CimSession FS01 – in der Regel mit Administratorrechten auf dem Server.

Wo Skripte enden: Get-Acl liefert Einträge, keine effektiven Rechte. Windows prüft die Einträge der Reihe nach, bis eine Verweigerung oder eine ausreichende Erlaubnis greift; wer über verschachtelte Gruppen dazugehört, was Verweigern-Einträge wegnehmen und wie Freigabe- und NTFS-Recht zusammenspielen, rechnet das Skript nicht aus. Ordner, die das prüfende Konto nicht lesen darf, landen als Fehlermeldung in der Konsole statt als Zeile in der Liste. Pfade mit mehr als 260 Zeichen verarbeiten Programme nur, wenn sie dafür eingerichtet sind. Und jeder Lauf beginnt von vorn: Den Vergleich mit dem letzten Mal und einen Nachweis zum Abzeichnen bauen Sie selbst.

Freigabe und NTFS: „Jeder: Vollzugriff“ auf der Freigabe

Auf einem Fileserver gelten zwei unabhängige Sätze von Berechtigungen: die der Freigabe und die NTFS-Berechtigungen der Ordner. Über das Netz gilt jeweils das strengere von beiden. Wer lokal oder per Remotedesktop auf dem Server arbeitet, für den zählen nur die NTFS-Rechte.

„Jeder: Vollzugriff“ auf der Freigabe ist deshalb nicht automatisch ein Fehler. Microsoft beschreibt diesen Weg ausdrücklich: Manche Administratoren setzen die Freigabe grundsätzlich auf Vollzugriff für „Jeder“ und regeln den Zugriff allein über NTFS. Dann müssen aber die NTFS-Rechte stimmen – „Jeder“ mit Schreibrecht in NTFS ist der eigentliche Befund. Umgekehrt kann eine strenge Freigabe großzügige NTFS-Rechte einschränken: Wer nur NTFS prüft, sieht dann mehr Zugriff, als über das Netz möglich ist.

Aufräumen: erst sichern, dann gezielt ändern

Finden ist das eine, ändern das andere – eine Änderung kann Zugriff nehmen, der noch gebraucht wird. Ein vorsichtiger Ablauf:

• Sichern: icacls D:\Daten\* /save D:\Sicherung\acl-daten.txt /t /c speichert die Zugriffslisten aller Dateien und Ordner unter D:\Daten – ohne den Ordner D:\Daten selbst. icacls D:\Daten\ /restore D:\Sicherung\acl-daten.txt schreibt sie zurück – und überschreibt dabei auch spätere Änderungen.
• Klären: Ist die SID wirklich verwaist – oder eine Funktions-SID, ein Konto aus einer anderen Domäne, ein migriertes Konto? Berechtigungen in den Systemordnern von Windows lassen Sie unangetastet.
• Am Ursprung ändern: Geerbte Einträge kommen von einem übergeordneten Ordner und werden dort entfernt, wo sie ausdrücklich gesetzt sind – im Explorer oder mit icacls D:\Daten\Projekt /remove *S-1-5-21-…-1107, das alle Einträge dieser SID aus der Zugriffsliste des Ordners entfernt.
• Breite Gruppen ersetzen: Statt „Jeder“ oder „Domänen-Benutzer“ eine Gruppe berechtigen, die genau die zuständigen Personen enthält.
• Kontrollieren: Danach erneut prüfen und mit dem Stand von vorher vergleichen.

Wichtig: /remove, /restore und Änderungen im Explorer wirken sofort. Probieren Sie Befehle, die Rechte ändern, zuerst in einer Testumgebung oder an einer Kopie aus, und ändern Sie produktive Freigaben nur mit Sicherung und in einem abgesprochenen Zeitfenster. Ein Berechtigungsbericht wie Zutritt ändert selbst nichts – er liefert die Befunde vorher und den Vergleich danach.

Zutritt: verwaiste SIDs und breite Gruppen im Berechtigungsbericht

Zutritt ist unser Berechtigungsbericht für Windows-Dateifreigaben. Zutritt liest die Freigabe- und NTFS-Berechtigungen einer Freigabe, eines ganzen Servers oder lokaler Ordner, löst Gruppen bis zur einzelnen Person auf und rechnet die effektiven Rechte wie Windows – mit der gespeicherten Reihenfolge der Einträge, Verweigern-Einträgen, Vererbung und Freigabe und NTFS zusammen. 15 Prüfregeln melden, was in diesem Ratgeber gesucht wird, jeweils mit Erklärung und Empfehlung:

• Verwaiste SID (ZT04)

  Einträge, Besitzer und Freigabeberechtigungen, deren Konto es nicht mehr gibt – aber nur, wenn die zuständige Kontendatenbank erreichbar war und die SID nicht kennt. Sonst steht dort „Unbekannt“. Funktions-SIDs, App-Pakete, Dienst-SIDs und Anmeldesitzungen gelten nie als verwaist.

• Breite Gruppe darf schreiben oder lesen (ZT01, ZT02)

  „Jeder“, „Authentifizierte Benutzer“, „Domänen-Benutzer“ und ähnliche Gruppen mit Schreibrecht (Hoch) oder Leserecht (Mittel) – gemeldet an dem Ordner, an dem der Eintrag gesetzt ist, mit dem Recht, das nach Verweigern-Einträgen übrig bleibt.

• Versteckte Ausnahmen und verschobene Ordner (ZT06, ZT14)

  Vererbung tief im Baum unterbrochen – ab Ebene 3 unter dem geprüften Ziel, einstellbar – und Ordner, die beim Verschieben ihre alten geerbten Rechte mitgenommen haben.

• Personen, deaktivierte Konten, Vollzugriff (ZT03, ZT12, ZT05)

  Rechte direkt an einer Person statt an einer Gruppe, eigene Rechte deaktivierter Konten und Vollzugriff für Konten und Gruppen ohne Administratorrolle.

• „Wer darf hier rein?“ und Freigabe für alle (ZT08)

  „Wer darf hier rein?“ zeigt pro Ordner jede Person mit ihrem effektiven Recht über Freigabe und NTFS. „Jeder“ oder „Authentifizierte Benutzer“ mit mindestens Ändern auf der Freigabe meldet Zutritt nur als Hinweis (Info).

• Excel, PDF und Vergleich

  Filterbare Excel-Arbeitsmappe mit jedem Eintrag, PDF mit Block zum Abzeichnen und der Vergleich mit dem letzten Lauf: neue und erledigte Befunde und wer jetzt mehr oder weniger darf. Was nicht lesbar war, steht als Befund im Bericht, statt still zu fehlen.

Zutritt liest nur: Es ändert keine Berechtigungen, Dateien oder Konten und braucht keinen Server, keinen Agenten und keinen Dienst. Im Zweifel zeigt Zutritt eher zu viel Zugriff als zu wenig. Für geplante Läufe gibt es eine Befehlszeile mit Exitcodes.

Ehrlich gesagt: Zutritt ist eine Vorabversion (0.1.2) und noch nicht signiert – SmartScreen kann warnen. Zutritt läuft unter Windows 10 ab Version 1809 und Windows 11 (x64). Active Directory löst es nur für die Domäne des prüfenden PCs auf; Gruppen aus vertrauten Domänen werden genannt, aber nicht aufgelöst, und die Auflösung ist bisher nur gegen ein simuliertes Verzeichnis getestet, noch nicht in einer echten Domäne. Freigabeberechtigungen liest Zutritt nur mit Administratorrechten auf dem Server, sonst rechnet es mit NTFS allein. Zutritt überwacht nicht dauerhaft, sondern läuft bei Bedarf oder als geplante Aufgabe. Zutritt ist kostenlos unter der MIT-Lizenz. Der Download folgt mit der Veröffentlichung.

Unser Produkt

Zutritt – Berechtigungsbericht für Dateifreigaben (NTFS und SMB)

Freigabe- und NTFS-Rechte bis zur Person, 15 Prüfregeln von der verwaisten SID bis „Jeder darf schreiben“, Excel und PDF zum Abzeichnen – nur lesend, für Windows 10 und 11.

Status: Demnächst · Demnächst

Mehr zu Zutritt Vergleich mit anderen Berechtigungsberichten

Die Wege im Vergleich

Über das Netz gilt jeweils das strengere von Freigabe- und NTFS-Recht. „Von Hand“ heißt: möglich, aber mit eigener Arbeit, etwa zwei Exporte vergleichen. Zutritt löst Active Directory nur für die Domäne des prüfenden PCs auf und ist dabei bisher nur gegen ein simuliertes Verzeichnis getestet.

Was passt wann?

• Ein einzelner Ordner, eine Frage

  Der Explorer: Sicherheit, „Erweitert“ und „Effektiver Zugriff“.

• Wo steht überall „Jeder“ oder eine bestimmte SID?

  icacls … /findsid … /t /c über den ganzen Baum – danach das Recht im einzelnen Ordner prüfen.

• Alle Einträge als Liste zum Filtern

  Ein PowerShell-Skript mit Get-Acl und Export-Csv – oder ein Berechtigungsbericht, der die Liste fertig liefert.

• Regelmäßige Berechtigungsprüfung mit Nachweis

  Ein Berechtigungsbericht mit effektiven Rechten, Vergleich mit dem letzten Lauf und PDF zum Abzeichnen, zum Beispiel Zutritt.

• Die SID beginnt mit S-1-15-3

  Eine Funktions-SID von Windows: nicht entfernen.

• Aufräumen

  Erst icacls … /save, dann jeden Befund klären und am Ursprung ändern – ein Bericht ändert selbst nichts.