Warum geht Script mit dieser MS Gruppe nicht?

[wos 0]

Hallo zusammen, bin jetzt nicht so der Powershell Guru, aber ich google mir mein Zeug so zusammen. Ein aber bereits funktionierendes Skript, welches den Ersteller-Besitzer aus einer Verzeichnisberechtigung entfernt ...

# ERSTELLER BESITZER aus ACLs entfernen
$IdentityRef = "ERSTELLER-BESITZER"
$ACL = Get-Acl $LocalInstDir 
$ACEs=(Get-Acl $LocalInstDir).Access | where {$_.IdentityReference -eq $IdentityRef}
$ACEs | foreach{
    try{
    $null=$ACL.RemoveAccessRule($_)
    Set-ACL $LocalInstDir $ACL
    "ACE für $IdentityRef erfolgreich entfernt"
    }
    catch{
    #keine ACE mehr vorhanden
    }
 }

... funktioniert einfach nicht, sobald ich ALLE ANWENDUNGSPAKETE (anstatt ERSTELLER-BESITZER) entfernen will.

 

Mit anderen Gruppen geht es schon, aber nicht dieses Anwendungspaketdingens. Ich hab es auch schon mit der englischen Benennung versucht, das hat nichts gebracht. Dann dachte ich, ich kann das evtl. mit der dazugehörigen SID realisieren (die steht ja im MSDN für die Gruppe drinnen), das krieg ich aber auch nicht hin-/umgebaut (weiss gar nicht üb das überhaupt geht).

 

Weiss einer, warum das Skript offensichtlich mit allen Gruppen geht, aber nicht diesem konkreten Ding? Per Mausklick ist die ganz einfach entfernt, es ist also nicht so, dass das gar nicht ginge. Wäre das mit der SID ein gangbarer Weg?

[lefg 276]

Moin

 

ist der Ablauf des Skriptes beobachtbar eventuell in Einzelschritten? Sind auftretende Fehler protokollierbar?

 

Ist der Ersteller/Besitzer überhaupt entfernbar? Wurde das händisch in dem selben Kontext schon einmal probiert?

bearbeitet 27. März 2017 von lefg

[wos 0]

Ja, wie geschrieben, kann man das händisch über die GUI machen. Ich weiss nicht, wie man das in Einzelschritten debuggen könnte oder geschweige denn, wo da irgendwo ein Log wäre. Aber es geht ja mit allen anderen Gruppen, die ich rausmachen wollte, nur mit dieser ALLE ANWENDUNGSPAKETE halt nicht. So falsch kann das Skript nicht sein, wahrscheinlich findet er den Namen nicht?! Wenn jemand weiss, wie man das auf die SID umbauen könnte, statt über den Namen, würde das sogar Sprachunabhängig gehen ...

[BOfH_666 577]

Hmmm .... ich kann das leider nicht nachvollziehen, da ich so eine Gruppe bei mir nicht finden kann. Aber was willst Du denn eigentlich erreichen? Warum willst Du denn diese spezielle zugriffsberechtigte Gruppe entfernen? Meistens sind diese Rechte ja aus einem bestimmten Grund gewährt. Vielleicht kannst Du hier auch mal einen Auszug aus Deinen ACLs posten. Eventuell erkennt ja jemand das Problem.

 

Übrigens kannst Du das hier:

$ACL = Get-Acl $LocalInstDir 
$ACEs=(Get-Acl $LocalInstDir).Access

so etwas verkürzen ...

$ACL = Get-Acl $LocalInstDir 
$ACEs=($ACL).Access

... dann brauch die Abrage nicht zweimal laufen.   ;)

[MurdocX 953]

Ich würde es mal damit probieren

$Pfad = "C:\Users\Jan\Desktop\Neuer Ordner"
$IstACL = Get-Acl -Path $Pfad

$BöseACL = $IstACL.Access | Where-Object {$_.IdentityReference -like "Ersteller-Besitzer"} 
$IstACL.RemoveAccessRule($BöseACL)

Set-Acl -Path $Pfad -AclObject $IstACL

:)

Dein "ForEach" gibt übrigens keinen Sinn, da jede AccessRule von Dir einzeln entfernt und die neue ACL dann auf das Objekt geschrieben wird. 4x AccessRule heißt 4x die Berechtigung auf eine Datei setzen und 4x eine weniger dazu schreiben. Am Ende hast du nix mehr  ;)

[NilsK 2.957]

Moin,

 

das Problem könnte das Leerzeichen sein. Dein Skript übergibt den Namen als Text. Besser wäre es, in der PowerShell immer ein Objekt zu übergeben.

 

Gruß, Nils

[wos 0]

Hallo zusammen,

 

erst mal danke für die Antworten, ich hab es aber auch damit nicht hingekriegt:

 

Hmmm .... ich kann das leider nicht nachvollziehen, da ich so eine Gruppe bei mir nicht finden kann. Aber was willst Du denn eigentlich erreichen? Warum willst Du denn diese spezielle zugriffsberechtigte Gruppe entfernen? Meistens sind diese Rechte ja aus einem bestimmten Grund gewährt.

 

Dank Dir für Deine sicherlich besten Absichten mir diese Frage zu stellen. Ich bin aber generell (so wie in meinem Fall auch) der Meinung, dass in 9 von 10 Fällen die Frage an sich am Problem vorbei geht und man sich diese meist sparen kann. Ich hab mir auch abgewöhnt, anderen diese Frage zu stellen. Für die meissten würde ich unterstellen, dass diese schon einen guten Grund haben, das machen zu wollen. Nix für ungut - ist nicht böse gemeint, nur meine Meinung. Aber so viel vielleicht dazu: Diese Gruppe ist bspw. standardmäßig im Programmverzeichnis eines Servers vorhanden auch auf einem W10 wird man die wohl finden.

 

Übrigens kannst Du das hier:

$ACL = Get-Acl $LocalInstDir 
$ACEs=(Get-Acl $LocalInstDir).Access

so etwas verkürzen ...

$ACL = Get-Acl $LocalInstDir 
$ACEs=($ACL).Access

... dann brauch die Abrage nicht zweimal laufen.   ;)

 

Danke auch für den Hinweis, wie man das besser über das Objekt lösen kann. So ist es sicherlich auch eleganter. Ich hab ich mir den bisherigen Powershell Code auch nur über Google zusammen geklaut, in der Hoffnung dass die, von denen ich abschreibe, vielleicht halbwegs einen Plan haben, was die da so machen.

 

Ich würde es mal damit probieren

$Pfad = "C:\Users\Jan\Desktop\Neuer Ordner"
$IstACL = Get-Acl -Path $Pfad

$BöseACL = $IstACL.Access | Where-Object {$_.IdentityReference -like "Ersteller-Besitzer"} 
$IstACL.RemoveAccessRule($BöseACL)

Set-Acl -Path $Pfad -AclObject $IstACL

 

Habe auf meinem Server 2012 R2 einen Ordner C:\Program Files (x86)\Test angelegt. Das Skript läuft durch und macht auch keinen Fehler. Es löscht aber nicht den Ersteller-Besitzer, das was ich vorher schon mit meinem so machen konnte.

 

Dein "ForEach" gibt übrigens keinen Sinn, da jede AccessRule von Dir einzeln entfernt und die neue ACL dann auf das Objekt geschrieben wird. 4x AccessRule heißt 4x die Berechtigung auf eine Datei setzen und 4x eine weniger dazu schreiben. Am Ende hast du nix mehr 

 

Das mag sein, dass das nicht so elegant geschrieben ist, wie es sein könnte. Leider krieg ich es mit den aufgezeigten Alternativen gar nicht mehr hin, dass auch nur eine Gruppe entfernt wird.

 

das Problem könnte das Leerzeichen sein. Dein Skript übergibt den Namen als Text. Besser wäre es, in der PowerShell immer ein Objekt zu übergeben.

 

Danke, an so was hab ich auch schon gedacht, dass es u.U. daran liegen könnte. Daher ja auch der Gedanke, wenn man meinen Ansatz (der vielleicht nicht so elegant gecodet ist, aber im Prinzip in der Lage ist, so eine Gruppe raus zu löschen) so umbauen kann, dass es bspw. direkt mit einer SID umgehen kann. Die SID für diese Gruppe wäre lt. MSDN ...

 

https://msdn.microsoft.com/en-us/library/cc980032.aspx

 

... die S-1-15-2-1. Ich weiss nur nicht, wie ich dem Skript quasi ein

... where Identity = "S-1-15-2-1"

... (oder wie man dass dann auch immer vom Syntax her schreiben muss) beibringen kann. Dann wäre das Ganze nämlich auch noch Sprachunabhängig.

 

Vielleicht hat ja noch einer den entscheidenden Tipp auf Lager. Irgendwie muss das doch mit dieser Powershell hinzubekommen sein (ist es auch sicherlich). Danke schon mal an alle für Ihre Antworten.

[MurdocX 953]

Habe auf meinem Server 2012 R2 einen Ordner C:\Program Files (x86)\Test angelegt. Das Skript läuft durch und macht auch keinen Fehler. Es löscht aber nicht den Ersteller-Besitzer, das was ich vorher schon mit meinem so machen konnte.

 

Das funktioniert bei mir einwandfrei. Ich vermute, dass du das auf Ordnern entfernen möchtest, die die Berechtigung vererbt bekommen haben. Probiere mein Skript mal mit einem einfachen Ordner auf dem Desktop aus und du wirst sehen es klappt.  ;)

EDIT:

 

Zum entfernen der Vererbung kannst du icacls.exe /inheritance:d nutzen.

[wos 0]

Hallo MurdocX,

 

Das funktioniert bei mir einwandfrei. Ich vermute, dass du das auf Ordnern entfernen möchtest, die die Berechtigung vererbt bekommen haben. Probiere mein Skript mal mit einem einfachen Ordner auf dem Desktop aus und du wirst sehen es klappt.  

 

da hast Du völlig recht, das vermutest Du richtig. Logo, dass das so nicht kann. Asche über mein Haupt.

 

In meinem Skript, wo vorher alles mögliche passiert, lege ich aber unterhalb des x86 Programmverzeichnisses ein neues Verzeichnis XXXXX an. Dann breche ich die Vererbung mit der Powershell auf und übertrage alle vorher vererbten Rechte direkt als ALC an dieses Verzeichnis. Bei "Geerbt von" steht dann "Keine". Wollt gerade noch einen Screenshot anhängen, aber das ist mir irgendwie nicht erlaubt, wird mir angezeigt. Egal - musst Du mir glauben, dass das aufgebrochen ist.

 

Bei meinem ersten Test, hatte ich mir blöderweise erspart, dass vorher noch aufzubrechen.

 

Lasse ich jetzt das Skript aber auf einem Verzeichnis mit aufgebrochener Vererbung laufen, dann klappt es mit deinem Beispiel, die ERSTELLER-BESITZER rauszulöschen. Rufe ich es ein 2. mal mit dem gleichen Verzheichnis und der gleichen Gruppe auf, so kommt ein Fehler, dass irgenwas nicht NULL sein darf. Wohl die nun nicht mehr in der ACL vorhandene Gruppe. Insofern logisch und ok ...

 

Rufe ich dein Skript dann wieder mit der Gruppe VORDEFINIERT\BENUTZER auf (was mit meinem geklappt hat), so kommt auch der NULL Fehler. Die Gruppe bleibt dann auch in den ACLs erhalten. Er kann diese wohl wegen eines Namensproblems nicht finden. Ich habe Versionen mit $_.IdentityReference -eq blabla und -like blabla gesehen. Die kann ich so leider nun nicht mehr raus löschen.

 

Auch bei ALLE ANWENDUNGSPAKETE klappt es nicht, wohl auch wegen der Benennung.

 

Um all diesen Namensproblemen aus dem Weg zu gehen, würde ich auch gerne einfach die SID nutzen. Aber so einfach wie sich das anhört ist es wohl nicht. Auf jeden Fall komme ich nicht dahinter, wie man das schreiben muss, dass die Gruppe über die SID quasi als Objekt gefunden wird. Die SIDs selbst in Erfahrung zu bringen, wäre nicht das Problem. Mit der SID könnte ich das Objekt wohl bestimmt da raus löschen, wenn ich wüsste wie die Syntax ist bzw. wie das geht.

[MurdocX 953]

Auch bei ALLE ANWENDUNGSPAKETE klappt es nicht, wohl auch wegen der Benennung.

 

In Wirklichkeit heißt "Alle Anwendungspakete" nämlich: "ZERTIFIZIERUNGSSTELLE FÜR ANWENDUNGSPAKETE\ALLE ANWENDUNGSPAKETE". Die Berechtigung lässt sich damit aber nicht entfernen. Zumindest über Powershell.

 

Hiermit funktioniert es. Den Befehl könnte man in die PS einbauen und Verzeichnisse über "ForEach" durchrödeln.  :)

icacls.exe "C:\Users\Jan\Desktop\Neuer Ordner" /remove:g "Alle Anwendungspakete"

[NilsK 2.957]

Moin,

 

Berechtigungen würde ich nur und ausschließlich mit SetACL automatisieren.

 

Gruß, Nils

[BOfH_666 577]

Ich bin aber generell (so wie in meinem Fall auch) der Meinung, dass in 9 von 10 Fällen die Frage an sich am Problem vorbei geht und man sich diese meist sparen kann. Ich hab mir auch abgewöhnt, anderen diese Frage zu stellen. Für die meissten würde ich unterstellen, dass diese schon einen guten Grund haben, das machen zu wollen. 

 

... und genau da ist meine Erfahrung eine ganz andere - ganz allgemein und besonders in Foren wie diesem hier. Ich frage IMMER erst mal nach dem Mehrwert. Wenn das Angeforderte weder die Leistung noch die Sicherheit verbessert, wozu dann den ganzen Aufwand betreiben? Gerade Anforderungen aus dem "nicht-technischen" Management sind nach meiner Erfahrung gerne mal pure Verschwendung von Zeit und Energie. Nur weil etwas technisch möglich ist, ist es noch lange nicht sinnvoll. Und gerade bei Berechtigungsanpassungen sind mir schon das ein oder andere mal die Nebenwirkungen später wieder auf die Füße gefallen.

Also denn ... ich drück die Daumen!   ;)  :)

[wos 0]

Hallo zusammen,

 

In Wirklichkeit heißt "Alle Anwendungspakete" nämlich: "ZERTIFIZIERUNGSSTELLE FÜR ANWENDUNGSPAKETE\ALLE ANWENDUNGSPAKETE". Die Berechtigung lässt sich damit aber nicht entfernen.

 

Das stimmt, auch mit dem Namen hatte ich es anfangs probiert (hatte diesen mit einem get-acl ermittelt), aber habe auch bemerkt, dass es damit auch nicht geht.

 

Berechtigungen würde ich nur und ausschließlich mit SetACL automatisieren.

 

Das würde ich auch gern so bevorzugen. Vielleicht fällt einem ja noch ein, wie man das gegen die SID machen könnte. Das liegt bestimmt an dem Namen! Ich werde mich parallel hierzu noch ein wenig durch die Gegend googeln ... falls ich auf die Lösung komme, schreib ich die natürlich hier rein ...

Hallo,

 

... und genau da ist meine Erfahrung eine ganz andere - ganz allgemein und besonders in Foren wie diesem hier. Ich frage IMMER erst mal nach dem Mehrwert. Wenn das Angeforderte weder die Leistung noch die Sicherheit verbessert, wozu dann den ganzen Aufwand betreiben? Gerade Anforderungen aus dem "nicht-technischen" Management sind nach meiner Erfahrung gerne mal pure Verschwendung von Zeit und Energie. Nur weil etwas technisch möglich ist, ist es noch lange nicht sinnvoll. Und gerade bei Berechtigungsanpassungen sind mir schon das ein oder andere mal die Nebenwirkungen später wieder auf die Füße gefallen.

Also denn ... ich drück die Daumen!   ;)  :)

 

also nochmal Danke für Deine Bedenken. Ich hab nur zum Ausdruck bringen wollen, dass in den verschiedensten Foren jemand einfach eine Frage stellt und oft, kommen dann einfach Gegenfragen, warum so und nicht so. Dann geht es plötzlich den ganzen Thread um solche Sachen, oft dann gar nicht mehr um die eigentliche Frage. Wenn der Threadstarter Glück hat, bekommt er seine Frage vielleicht nach 30 anderen Posts dann mal beantwortet. Daher denke ich, dass das in 9 von 10 Fällen eigentlich nicht nötig wäre.

 

Ich seh aber, ich komm jetzt wohl doch nicht umhin, das jetzt darzulegen, auch wenn ich mich jetzt dann leider schon wieder aufregen muss *lach*:

 

Unterhalb von x86 Programme erstelle ich ein Programmverzeichnis. Die Vererbung wird unterbrochen. Dort kommt eine eigene Anwendung rein, die nicht im entferntesten irgendein Recht bräuchte, dass eine Windows App oder was das sein möchte, darauf Zugriff haben soll. Wenn ich das Wort App schon hör, dreht sich mir alles um. Dieser ganze App Mist auf einem Server, könnt mich schon wieder aufregen wenn ich nur daran denke was MS die letzten Jahre so verzapft, früher hatte ich die Fahne für die noch hochgehalten. Ich muss jetzt somit auch aufhören zu schreiben, sonst dreh ich gar noch durch ...

 

Auf jeden Fall, handet es sich um eine eigene Anwendung, die einen Webservice zur Verfügung stellt. Ich weiss, wer, welche Dienste und Accounts darauf Zugriff bekommen sollen. Ganz sicher gehört da diese App Gruppe und auch normale Benutzer oder Ersteller-Besitzer nicht dazu und daher will ich auch nicht, dass irgendwelche Apps  über die Gruppe darauf zugreifen dürfen. Es wird sich daher auch nicht zu einem Nachteil entwickeln, wenn die Gruppe weg ist.

 

So ... kurz durchatmen ... Om ... Nix für ungut, aber wenn ich über solche Dinge nachdenken muss und warum das bei MS alles so mistig wurde, kann ich mittlerweile nicht mehr ruhig bleiben ,)

[BOfH_666 577]

Alles klar ... dann weiß ich jetzt Bescheid ... der ganze Aufwand für keinen messbaren technischen Mehrwert.  SCNR    :D  :)  ;)  :cool:  :p

bearbeitet 30. März 2017 von BOfH_666

[NilsK 2.957]

Moin,

 

also nochmal Danke für Deine Bedenken. Ich hab nur zum Ausdruck bringen wollen, dass in den verschiedensten Foren jemand einfach eine Frage stellt und oft, kommen dann einfach Gegenfragen, warum so und nicht so. Dann geht es plötzlich den ganzen Thread um solche Sachen, oft dann gar nicht mehr um die eigentliche Frage. Wenn der Threadstarter Glück hat, bekommt er seine Frage vielleicht nach 30 anderen Posts dann mal beantwortet. Daher denke ich, dass das in 9 von 10 Fällen eigentlich nicht nötig wäre.

 

ach je. Nicht schon wieder diese Diskussion. Wenn du wüsstest, wie oft wir hier an irgendwas rumlaborieren, nur um hinterher festzustellen, dass man mit Kenntnis der Hintergründe viel schneller zu einem besseren Ergebnis gekommen wäre.

 

Du kannst uns glauben, dass wir auch unsere Erfahrungen haben.

 

Gruß, Nils