none
excecution policy, gpo startup script RRS feed

  • Frage


  • hallo zusammen,

    wir haben mittels GPO Computer und User Startup (*.cmd) Scripts für diverse adhoc Workarounds.

    nun habe ich im Computer Startup Script auch einen *.ps1 Aufruf.

    powershell \\server\share\myscript.ps1

    welche execution policy benötige ich damit das Script im Computer Account (SYSTEM ACCOUNT) läuft und auf einen NetzwerkShare eine Datei anlegen darf.

    Wenn es hilft könnte ich die ps1 auch vorher auf c: kopieren.


    Chris

    Dienstag, 4. Juli 2017 10:26

Antworten

  • Hallo Chris

    Für dass ein Powershell-Skript ausgeführt werden kann, muss die Ausführungsrichtlinie angepasst werden. Der Hey-Scripting Guy-Blog hat hier einen Blogeintrag dazu veröffentlicht, wie man ein Skript vertrauenswürdig machen kann (sofern das gewünscht ist, es ist auch "unrestricted" möglich). 
    Wenn du für jede Quelle offen machen willst, kannst du einfach 

    Set-ExecutionPolicy Unrestricted

    eingeben. Dies erlaubt dann das Ausführen jeder Art von Skript. 

    Was macht das Skript, dass es als SYSTEM laufen muss?

    Gruss
    Fahiko

    • Als Antwort markiert -- Chris -- Dienstag, 4. Juli 2017 17:27
    Dienstag, 4. Juli 2017 11:00
  • Hallo Chris,

    erstmal zum Powershell Script. Sofern das nicht entsprechend signiert ist, würde ich Dir empfehlen, einfach ein *.cmd auszuführen, welches die notwendige *.ps1 mit dem Paramter "-executionpolicy bypass" startet.

    Ein GPO in unserer Struktur startet z.B. eine *.bat vom \\fqdn\netlogon\.
    In dieser .bat steht dann folgendes drin: 

    start powershell.exe -ExecutionPolicy Bypass -Command "\\fqdn\netlogon\Filename.ps1"

    Wenn Du jetzt Dein Script als SYSTEM ausführen lässt, benötigst Du aber noch
    a) eine Freigabe, wo das Script liegt, auf der "Jeder / Everyone" NTFS Lesen darf, und im Share "Lesen" darf.

    b) das gleiche auf deinem NetzwerkShare / Ordner, wo Du die Datei erstellen willst, allerdings mit dem "Schreiben/Ändern" Recht.

    Das Ganze wäre also ziemlich unsicher... sofern Du nicht für "Jeden" das Recht zum Löschen (NTFS) verweigerst, während Du das Schreiben erlaubst. Die Freigabe machst Du dann mit "$". In der Freigabe muss "Ändern" weiterhin erlaubt sein. Trotzdem darf dann Jeder die Dateien lesen...

    Ich würde Dir daher empfehlen, das Script via GPO im Kontext des angemeldeten Benutzers ausführen zu lassen, damit Du das Zugriffsrecht auf den Share über Sicherheitsgruppen steuern kannst. Möglich wären auch die "Authentifizierten Benutzer" oder "Domänen Benutzer", was ich persönlich aber auch nicht mag. 
    Am einfachsten, Du nimmst einfach die Sicherheitsgruppe, auf die das GPO gefiltert ist.

    Hoffe, ich konnte Dir helfen. 

    Mfg, Jannik

    • Als Antwort markiert -- Chris -- Dienstag, 4. Juli 2017 17:26
    Dienstag, 4. Juli 2017 14:09

Alle Antworten

  • Hallo Chris

    Für dass ein Powershell-Skript ausgeführt werden kann, muss die Ausführungsrichtlinie angepasst werden. Der Hey-Scripting Guy-Blog hat hier einen Blogeintrag dazu veröffentlicht, wie man ein Skript vertrauenswürdig machen kann (sofern das gewünscht ist, es ist auch "unrestricted" möglich). 
    Wenn du für jede Quelle offen machen willst, kannst du einfach 

    Set-ExecutionPolicy Unrestricted

    eingeben. Dies erlaubt dann das Ausführen jeder Art von Skript. 

    Was macht das Skript, dass es als SYSTEM laufen muss?

    Gruss
    Fahiko

    • Als Antwort markiert -- Chris -- Dienstag, 4. Juli 2017 17:27
    Dienstag, 4. Juli 2017 11:00
  • Irre ich mich, oder hat das lokale System Konto gar keine Rechte im Netz ... es ist ein lokales Konto. Das für müsstest Du dann wohl eher ein Domänen-Konto nehmen, welches dort berechtigt ist.

    Ansonsten müsstest Du ALLE Computer-Konten, auf denen das Script laufen soll, auf der Freigabe als berechtigt eintragen.


    Grüße - Best regards

    PS:> (79,108,97,102|%{[char]$_})-join''

    Dienstag, 4. Juli 2017 11:03
  • Hallo Chris,

    erstmal zum Powershell Script. Sofern das nicht entsprechend signiert ist, würde ich Dir empfehlen, einfach ein *.cmd auszuführen, welches die notwendige *.ps1 mit dem Paramter "-executionpolicy bypass" startet.

    Ein GPO in unserer Struktur startet z.B. eine *.bat vom \\fqdn\netlogon\.
    In dieser .bat steht dann folgendes drin: 

    start powershell.exe -ExecutionPolicy Bypass -Command "\\fqdn\netlogon\Filename.ps1"

    Wenn Du jetzt Dein Script als SYSTEM ausführen lässt, benötigst Du aber noch
    a) eine Freigabe, wo das Script liegt, auf der "Jeder / Everyone" NTFS Lesen darf, und im Share "Lesen" darf.

    b) das gleiche auf deinem NetzwerkShare / Ordner, wo Du die Datei erstellen willst, allerdings mit dem "Schreiben/Ändern" Recht.

    Das Ganze wäre also ziemlich unsicher... sofern Du nicht für "Jeden" das Recht zum Löschen (NTFS) verweigerst, während Du das Schreiben erlaubst. Die Freigabe machst Du dann mit "$". In der Freigabe muss "Ändern" weiterhin erlaubt sein. Trotzdem darf dann Jeder die Dateien lesen...

    Ich würde Dir daher empfehlen, das Script via GPO im Kontext des angemeldeten Benutzers ausführen zu lassen, damit Du das Zugriffsrecht auf den Share über Sicherheitsgruppen steuern kannst. Möglich wären auch die "Authentifizierten Benutzer" oder "Domänen Benutzer", was ich persönlich aber auch nicht mag. 
    Am einfachsten, Du nimmst einfach die Sicherheitsgruppe, auf die das GPO gefiltert ist.

    Hoffe, ich konnte Dir helfen. 

    Mfg, Jannik

    • Als Antwort markiert -- Chris -- Dienstag, 4. Juli 2017 17:26
    Dienstag, 4. Juli 2017 14:09
  • ja müsste passen.

    -force noch erforderlich sonst kommt noch die Meldung JA, ALLE, NEIN usw. was bei GPO Script nicht sichtbar wäre.


    Chris

    Dienstag, 4. Juli 2017 17:27
  • > Irre ich mich, oder hat das lokale System Konto gar keine Rechte im Netz ... es ist ein lokales Konto.

    Ja Du irrst Dich :-) SYSTEM impersoniert extern als der Computeraccount - darf also alles, wo das Computerkonto (genau wie ein Benutzerkonto) direkt oder durch Gruppenmitgliedschaften entsprechende Rechte hat.

    Freitag, 7. Juli 2017 11:40
  • Ja ... nee ... das meinte ich schon so ...  nach meiner Erfahrung trägt man ja selten irgendwo ein Computerkonto als zugriffsberechtigt auf irgendeiner Ressource ein ... jedenfalls keine Clients ... meine ich.  ;-)

    Grüße - Best regards

    PS:> (79,108,97,102|%{[char]$_})-join''

    Freitag, 7. Juli 2017 12:55
  • > nach meiner Erfahrung trägt man ja selten irgendwo ein Computerkonto als zugriffsberechtigt auf irgendeiner Ressource ein ... jedenfalls keine Clients

    Da unterscheiden sich unsere Erfahrungen aber ziemlich :-)

    Wir schieben tendenziell alles, was ein Client ausführen muß, per Software Deployment lokal auf den Client. Wenn es aber mal schnell gehen muß, dann holt der sich das auch von einem UNC-Pfad. Und dort werden dann Domänencomputer berechtigt (oder was immer angemessen ist). Druckertreiber sind hier z.B. dabei.

    Freitag, 7. Juli 2017 13:24
  • Da unterscheiden sich unsere Erfahrungen aber ziemlich :-)

    ... scheint wohl so ;-) ... aber unter anderen deshalb bin ich ja hier unterwegs ... um von Anderen zu lernen ... also danke.

    Grüße - Best regards

    PS:> (79,108,97,102|%{[char]$_})-join''

    Freitag, 7. Juli 2017 13:39