none
Script remote persistent starten unter lokalem User RRS feed

  • Frage

  • Hallo,

    ich habe jetzt stundenlang versucht folgendes Problem zu lösen und kam zu nix. Also frage ich mal euch ;-)

    Umgebung: AD-Domäne, Server 2003 als DC, Win7 Clients.

    Ich versuche für Wartungszwecke und remotejobs, zentral von einem Adminrechner aus, auf den anderen Rechnern ein Script/Programm auszuführen. Sowas kriegt man per powershell remoting ja noch leicht hin. Aber dann wirds tricky.

    • Das Programm soll auch dann noch weiter laufen, wenn die remote Verbindung unterbrochen wird. 
    • Außerdem sollte man remote wieder auf das Programm zugreifen können, also den remote laufenden powershell-thread irgendwie wieder "übernehmen" können.
    • Und als Letztes sollte das Programm nicht unter dem Domänen-Administrator Account laufen, den man normalerweise für powershell-remoting verwendet, sondern unter einem, auf dem remoten Client vorhandenen, lokalen User mit eingeschränkten Rechten.

    Puhh, unter Linux habe ich 10 min Recherche gebraucht bis ich wusste wie das geht (ssh und "screen"-Tool), aber unter Windows komme ich nicht weiter. Kann mir jemand mal bitte auf die Sprünge helfen?

    Vielen Dank

    Gruß

    Sonntag, 8. Dezember 2013 11:29

Antworten


    1. Das Programm soll auch dann noch weiter laufen, wenn die remote Verbindung unterbrochen wird. 
    2. Außerdem sollte man remote wieder auf das Programm zugreifen können, also den remote laufenden powershell-thread irgendwie wieder "übernehmen" können.
    3. Und als Letztes sollte das Programm nicht unter dem Domänen-Administrator Account laufen, den man normalerweise für powershell-remoting verwendet, sondern unter einem, auf dem remoten Client vorhandenen, lokalen User mit eingeschränkten Rechten.

    Zu 1. 2. (und 3.)
    Ab der PowerShell 3.0 gibt es genau dafür die Disconnected Sessions.
    Wenn alle beteiligten Rechner PowerShell 3.0 (nach) Installiert haben, kannst du diese benutzen.

    about_Remote_Disconnected_Session

    http://technet.microsoft.com/en-us/library/jj149006.aspx

    Wenn nicht wird es schwierig.

    Zu 1.
    Du kannst du mit deinem Domänen Admin Account auf dem Zielrechner einen Scheduled Job erstellen (Windows Aufgaben Planung) und diesen Job mit dem Gewünschten Account sofort starten lassen.
    Oder du nimmst PSExec von WindowsInternals
    Ein reconnect ist da nicht möglich, ist aber eigentlich auch nicht nötig, wenn du die Ergebnisse fein Loggst und diese Logfile remote abholst.

    Zu 3.
    Das wird schwierig. Da gibt es mehrere Lösungswege.
    Lokale User Accounts in einer Domänen Umgebung zu nutzen, ist meist nicht sehr Ziel-führend!
    Richte am besten einen Domänen Account, nur für diese Aufgabe ein (bei dem das Passwort nicht gewechselt werden muss).
    Dann kannst du diesen auch in den Remote Sessions ordentlich benutzen.

    3.1 Du richtest einen constrained und delegated Remoting-Endpoint ein. Dies würde dann wieder mit den Disconnected Sessions harmonieren. Ob dies mit Lokalen Accounts geht weiß ich nicht.
    Delegated Administration in Windows PowerShell v3
    http://www.vinithmenon.com/2012/11/delegated-administration-in-windows.html

    3.2 Scheduled Job einrichten (Windows Aufgaben Planung) der mit den Credentials des Lokalen Accounts läuft.

    3.3. Du hinterlegst (verschlüsselt) das Passwort (die Credentials) von dem User und Startest einen Prozess mit Start-Prozess und den Credentials.
    Passwörter ordentlich zu hinterlegen ist nicht einfach ;-) aber nicht unmöglich.
    Wenn du dir Datei in der die Credentials liegen so absicherst, das nur die beiden Accounts Zugriff haben und das Passwort verschlüsselt ist sollte das gehen.


    PowerShell Artikel, Buchtipps und kostenlose PowerShell Tutorials + E-Books
    auf der deutschsprachigen PowerShell Community

    Mein 21 Teiliger PowerShell Video Grundlehrgang
    Deutsche PowerShell Videos auf Youtube
    Folge mir auf:
    Twitter | Facebook | Google+

    • Als Antwort vorgeschlagen Alex Pitulice Mittwoch, 11. Dezember 2013 08:34
    • Als Antwort markiert Alex Pitulice Montag, 16. Dezember 2013 10:04
    Montag, 9. Dezember 2013 09:32