NTFS-Berechtigung angeblich vererbt, im übergeordneten Ordner jedoch nicht sichtbar

Misdemeanor

Lt. Junior Grade
Registriert
Mai 2009
Beiträge
510
Hallo miteinander,

ich möchte einen Fileserver mit knapp 15.000 Unterordnern digital entrümpeln und zahlreiche Zugriffsberechtigungen anpassen oder entfernen. U.a. haben sich mit der Zeit div. Userkonten angehäuft, die nur noch als verwaiste SIDs existieren und dort u.a. als Owner für div. Ordner eingetragen sind.

Aber ich habe ein Problem beim Entfernen der entsprechenden Berechtigungen aufgrund vermeintlicher Vererbungseinschränkungen.

Wieso das so ist, zeige ich gerne am nachfolgenden Beispiel:
1684156807761.png

Wie man sieht, gibt es einen verwaisten Eintrag als Zeugnis einer früheren Gruppen- oder Benutzerberechtigung mit der Bezeichnung S-1-21-1583696848-xxxxyyyyzz...

Klicke ich auf "Edit" > wähle die SID S-1-21-1583696848-xxxxyyyyzz...usw. aus > "Remove" führt zu folgender Fehlermeldung:
1684156976301.png


Aaah verstehe - es muss im übergeordneten Ordner dieselbe SID existieren, die ich dort oben entfernen muss, und dann geht's. Oder etwa nicht?

Da hilft also nur der Klick auf "Advanced" und man sieht, dass der Owner auf dieser dämlichen SID basiert und dass die Berechtigung vom übergeordneten Objekt "D:\TST\Applikationen\" kommt ("Inherited from").
1684157180947.png


Also setze ich als ersten Schritt den Owner auf die "Domänen-Admins"-Gruppe:
1684159038494.png


Dann, denke ich, wechsele ich zum darüberliegenden Ordner.

Das Seltsame ist: hier ist der Owner bereits die "Domänen-Admins"-Gruppe und in der Liste "Permission entries" taucht diese dubiose SID überhaupt nicht auf, auch unter Advanced ist diese nicht zu finden:
1684157344392.png


Hier beißt sich die Katze in den Schwanz. Wie kann die Vererbung vom übergeordneten Objekt kommen, in welchem selbst aber keine solche SID steht? Ich kann mir nur weiterhelfen, indem ich die Vererbung ausschalte, aber das möchte ich lieber nicht, zumal weitere Vererbungsregeln damit u. U. außer Kraft gesetzt werden könnten.

Weiß hier jemand Rat, wieso das so ist? Habe ich einen Denkfehler in meinen Überlegungen oder ist das mal wieder "works by design" nach Windows?

Danke vorab!
 
Zuletzt bearbeitet:
Den „dreckigen“ Weg hab ich einmal gemacht bei der Umstellung einer Struktur hier.

1. Neue Ordnerstruktur anlegen mit den Rechten die gewünscht sind.

2. alte Struktur auf einen Datenträger kopieren FAT32 ist. Achte darauf das Ordner/Dateinamen nicht zu lang sind.

Bei diesem Kopieren verliert alles die NTFS Rechte.

3. Ordner /Dateien in neue Struktur kopieren.
 
  • Gefällt mir
Reaktionen: andy_m4, whats4, Col.Maybourne und 3 andere
Daher macht man das auch mit Gruppen und nicht mit einzelnen Konten 😉

Schau mal, ob du de Rechte ggfs "speziell" gesetzt hast, passiert durchaus mal, dass der Entry-Point auf der Freigabe ja erst ab Ordner xyz in der Struktur kommt, so wie es halt angebunden wurde.
 
Sieht so aus, als hätte ich die Lösung für dieses (bzw. für mein) Problem gefunden. 🙄

Schritt #1: Der User lässt sich wg. angeblicher Berechtigung im übergeordneten Ordner nicht löschen (Szenario wie gehabt).
1684218478380.png


Schritt #2: Im "Sharing"-Tab desselben "Eigenschaften"-Fensters auf den Button "Share..." klicken:
1684218568878.png


Schritt #3: <Unknown Contact> entfernen und das Share erneut freigeben/einstellen:
1684218626817.png


Wer hätte das gedacht? Geht man erneut in die Sicherheitseinstellungen und will nun die Berechtigung der verwaisten SID entfernen, geht das ganz problemlos ... au weia – das hat mich gestern echt Stunden und Nerven gekostet.

Jetzt muss ich mir nur noch ein PowerShell-Script überlegen, mit dem ich in der Lage bin, diese Problemfälle aufzustöbern.
Ergänzung ()

KoKane schrieb:
Daher macht man das auch mit Gruppen und nicht mit einzelnen Konten 😉

Schau mal, ob du de Rechte ggfs "speziell" gesetzt hast, passiert durchaus mal, dass der Entry-Point auf der Freigabe ja erst ab Ordner xyz in der Struktur kommt, so wie es halt angebunden wurde.
Ich hab' so ziemlich alles versucht mit dem Wissen, was mir über Shares bekannt ist, u.a. als lokaler Admin auf dem Fileserver, in der Annahme (oder stillen Hoffnung), hier weiterzukommen, über das Get-Acl-Cmdlet in allen Formen und Farben und das einzig auffällige ist/war, dass der Benutzer im Security-Dialog quasi keinerlei Rechte angekreuzt hatte, weder bei Allow, noch bei Deny. Ganz unten steht "Special Permissions" ausgegraut, und die scheinen von der o.g. spefizischen Freigabe zu kommen.
 
Zuletzt bearbeitet: (Screenshots went missing)
  • Gefällt mir
Reaktionen: rezzler und KoKane
Wenn die Lösung funktioniert, ists ne gute Lösung 😎 danke für die Rückmeldung!
 
  • Gefällt mir
Reaktionen: Misdemeanor
Zurück
Oben