Dateiberechtigungen ändern

[rb-dewis 0]

Hallo!

Ich spiele mich schon ewig herum und habe einiges, aber leider die Info zu den aktuellen Dateiberechtigungen kann ich nicht auswerten:

 

Ich möchte bei einem Ordner, alle Dateien und Unterdateien (nur Objects) für die aktuellen eingetragenen Benutzer die Berechtigungen ändern, außer für definierte Benutzer, da soll keine Änderung rein.

Daher muss ich bevor ich Rechte setze, die aktuellen Benutzer rausfinden und dann umändern.

 

Hier ist was ich jetzt habe. Ich weiß nicht, wie ich die Benutzer korrekt auslese :|

Bitte um Hilfe

$path = "C:\daten\Neuer Ordner"
$list = get-childitem $path -Recurse |get-childitem |where {$_.IdentityReference}|foreach-object {$_.fullname}
$Right="Read"

foreach ($file in $(Get-ChildItem $path )) 
{

  get-acl $file | $benutzer = $_.identidyreference.AccessToString
  #wenigstens dass ich einen Benutzer bekomme oder ähnliches
  #ab hier sollte eine weitere Schleife für die Benutzer sein, die alle gefundenen umändert

  new-object System.Security.AccessControl.FileSystemAccessRule($benutzer,$Right,"Allow")

  Add this access rule to the ACL
  $acl.SetAccessRule($rule)
  
  Write the changes to the object
  set-acl $File.Fullname $acl
}

bearbeitet 11. Oktober 2017 von rb-dewis

[zahni 554]

Hallo und willkommen im Forum.

 

So ganz verstehe ich die Aufgabe  nicht. Windows kennt  Vererbung der  Rechte.

Einfach auf der höchsten Ebene Das Recht anpassen und nach  unten vererben.

[rb-dewis 0]

hallo.

alles ohne vererbung weil das skript solll täglich alle dateien auf read only setzen.

alle täglich neuen dateien sollen read write sein und am ende des tages werden neue dateien vom tag read only gesetzt.

 

so als dokumenten system

[Dukel 454]

Das ist alles aber kein Dokumentensystem. Wenn es um rechtliche Archivierung geht nutzt das nichts und auch für ein Archivsystem ist das eher ein Krampf.

[zahni 554]

Selbst dafür muss man die aktuellen Rechte nicht  lesen. 

 

Das hier könnte helfen:  https://technet.microsoft.com/de-de/library/cc753525%28v=ws.10%29.aspx

[rb-dewis 0]

Hi!

ich sehe nicht, wie die aktuell eingetragenen Benutzer (ohne sie zu kennen) geändert werden können.

Es ist ein Dokumentensystem. Vielleicht nicht rechtlich gültig, aber es ändert überall alle Rechte auf Leserechte, sodass es notwendig ist, die schreibgeschützte Datei zu kopieren, neu zu benennen und sie so abzuspeichern.

Während des Tages ist dieses neue Dokumente dann veränderbar und löschbar, aber nach Mitternacht soll auch das wieder mit Leserechten ausgestattet werden.

 

Vererbung ist hier eine gute Frage, aber es werden überall Gruppen hinterlegt sein und basierend auf den Gruppen sind dann für die Benutzer die Rechte geändert.

Ich kann nur die Gruppen nicht im Skript fix reinschreiben, weil die Windows-Explorer direkt geändert werden sollen. 

 

Aber vielleicht interessiert sich ja nur wer fürs Coding bzw das Skript dahinter.

Weißt du, wie du das skripten würdest? Oder hast du noch Fragen?

 

Lg, Roman

[BOfH_666 577]

Hi!

ich sehe nicht, wie die aktuell eingetragenen Benutzer (ohne sie zu kennen) geändert werden können.

 

Ich glaub, ich habs noch nicht so ganz.  :suspect:  :schreck:  :nene:  Wenn Du sowieso Gruppen zuweisen möchtest, die dann nur lesen können sollen, wenn ich das bis dahin richtig verstanden habe, dann ist doch völlig egal, wer bis dahin irgendwelche anderen Rechte hatte. Du ersetzt ALLE bisher existierenden Rechte durch die von Dir gewünschten neuen und basta, oder? ... und das geht, wie zahni schon geschrieben hatte, mit icacls.  .... oder fehlt mir doch noch 'ne Ecke?

[rb-dewis 0]

Das wäre dann natürlich sehr cool, wenn bei einer Änderung der Rechte von Read/Write auf Read dann ersichtlich ist, welche Datei geändert wurde und welche Benutzer/Gruppe als LOG-Datei.

 

Aber noch bin ich leider dabei, die IdentityReference auszulesen. 

Ich vermute aber, dass ich noch eine Schleife mit for each mit der Identitiy-Reference machen muss, weil ich ja pro Benutzer/Gruppe einmal das Recht dort setzen muss.

Also pro Datei und pro gelisteten Benutzer.

 

Stimmt soweit oder??

Die Ordner werden per Windows-Explorer geändert. Dh wenn im Überordner der MaxMeier hinzugefügt wird und für die Unterordner auch gilt, so muss der MaxMeier um Mitternacht auch mitbearbeitet werden.

 

Ist vielleicht eine nicht so leichte Aufgabenstellung, aber ich denke mit Powershell funktionierts. Ich hätte auch gerne jemand für ein wenig Nachhilfe was bezahlt. Ich kenne ungefähr die einzelnen Schritte aber ich kanns nicht in Powershell reinkrigen. Daran liegts :|

Ordner1

-Datei1.1

-Datei1.2

 

---Ordner2

---Datei2.1

---Datei2.2

 

--Ordner3

usw

 

Auf Ordner1 und Ordner2 und Ordner3 werden per WIndows-Explorer Rechte vergeben. Diese Rechte sollen laufend erweitert/geändert werden. Es sollen alle Berechtigungen von den Ordner auf die Unterordner übertragen werden, aber um Mitternacht wird alles geändert auf Lesen. Schreiben in die Ordner ist weiterhin OK, dh Ordner selbst sollen so bleiben wie sie sind und dürfen nur nicht umbenannt/verschoben werden.

 

Da in Windows Explorer die Rechte geändert werden, kann im Skript fixe Benutzer/Gruppen nicht hinterlegt werden.

Daher das mit dem auflisten/rausfinden und in einer Schleife jeweils abarbeiten, korrekt?

[NilsK 2.934]

Moin,

 

bevor wir uns jetzt hier einen abbrechen und dein Konstrukt zu verstehen versuchen, wäre es hilfreich, wenn du mal genau beschreibst, was du eigentlich warum erreichen möchtest.

 

Gruß, Nils

[rb-dewis 0]

Hallo, 

 

danke NilsK.

siehe Post #8 von mir, da steht es.

 

Ich versuche etwas zu coden, das so aussieht wie das hier

$path = "C:\daten\Neuer Ordner" 
$Right="Read"
$ExcludeBenutzer = "domain\Administratoren;domain\Benutzer1;domain\Benutzer2"

foreach ($file in $(Get-ChildItem $path -Recurse)) {
    Get-Acl $file  | foreach ($Benutzer in $_.IdentityReference) {
        if $Benutzer =! $ExcludeBenutzer {

           $rule = new-object System.Security.AccessControl.FileSystemAccessRule($Benutzer,$Right,"Allow")
           $acl.SetAccessRule($rule)
           set-acl $File.Fullname $acl
        }
    }
}

[zahni 554]

Dann fragen wir mal anders: Kennst Du  die  ACL nicht, oder  vergibt sich  hier  jeder selbstständig die  Rechte?

Benutzern sollte man eh keine Rechte  erteilen, sondern Gruppen. Also eine Gruppen  "Schreiben"  und eine  Gruppe "Lesen". Nur so als Beispiel.

[Dukel 454]

In #8 steht nur was du versuchst, aber nicht warum. Warum sollen alle Dateien Read Only gesetzt werden?

[rb-dewis 0]

Warum die Dateien so gesetzt werden sollen?

Weil es die Aufgabenstellung/Auftraggeber so wollen?

 

Die möchten, dass alles was aktuell in dem Ordner ist, auf Leserecht gesetzt wird.

Aber trotzdem dürfen berechtigte Benutzer (in einer Gruppe) am nächsten Tag wieder erneut in die Ordner schreiben, aber bestehende Dateien nicht verändern.

 

Ist das Warum wirklich so wichtig, als das, dass es so gewünscht ist oder gibt es eine bessere Alternative?

Wie würdest du das abbilden?

 

Es gibt bestimmte Ordner, da sollen nur bestimmte User drauf zugreifen können und es gibt Ordner wo bestimmte Gruppen und User zugreifen.

Daher ist das individuell. 

Benutzer-Berechtigen tun nur weitere bestimmte Benutzer, also nicht alle.

 

War mein Skript soweit ungefähr klar? Das funktioniert halt leider noch nicht, weils nicht richtig syntaxmäßig ist.

[Dukel 454]

Alles ist eine bessere Alternative als ein Gefummel mit den Dateiberechtigungen.

Wieso muss das täglich passieren? Darf man während des Tages die Dateien verpfuschen, aber einen tag später nicht mehr?

 

Warum darf nach einem Tag nur noch gelesen werden? Rechtliche Gründe? Datenschutz? Versionierung? ... ???

Was sind das für Dokumente in den Ordnern?

[NilsK 2.934]

Moin,

 

wenn die Angaben in #8 ausgereicht hätten, hätte ich ja nicht gefragt. :rolleyes:

Und ja, natürlich ist es wichtig, warum eine Frage gestellt wird. Wenn man den Hintergrund und das eigentliche Ziel nicht kennt, macht man sich oft viel Arbeit, um hinterher festzustellen, dass doch wieder alles anders ist. Glaub mir, das passiert hier ständig, und deshalb frage ich auch ständig nach.

 

Also bitte noch mal die eigentliche Anforderung beschreiben, oft hilft es auch, ein paar Worte zum Use Case zu sagen. Sonst wird das hier nix.

 

Danke.

 

Gruß, Nils