none
Benutzer Powershellskripte mit erhöhten Rechten ausführen lassen? RRS feed

 > 

  • Frage

  • Question
    Anmelden
    0
    Anmelden

    Hallo liebe Comunnity,

    ich arbeite grade in meiner Testumgebung an einem Monitoringsystem was ich zukünftig möglicherweise verwenden möchte.

    Das System basiert dabei auf einem Monitoring-Server (Linux) und einem Agent, welcher auf einem Server der überwacht wird, installiert ist.

    In dem Ordner des Clienten, können auszuführende Checks als Powershellscripte, oder exen etc. abgelegt werden. Der Agent ist anschließend dazu in der Lage dieses aus zu führen. Problem allerdings ist, das der Monitoring-Server den Befehl zum ausführen des Check an den Clienten sendet, d.h. es wird der befehl übermittelt "führe Script x.ps1, mit powershell aus".

    Dies führt allerdings dazu, dass der Monitoring-Server auch alle möglichen anderen Befehle an die Powershell-Komandozeile schicken kann, unter anderem auch schädliche Befehle, insofern der Monitoring-Server von jmd. übernommen wurde.

    Dieses Problem lässt sich allerdings umgehen, sofern ich dem Benutzer des Agenten, die Rechte auf die administrative Powershell entziehe.

    Dabei laufe ich allerdings in ein weiters Problem, da, mal als Beispiel genannt, der Befehel "Get-WBsummary" nur in der Administrativen Powershellkonsole funktioniert.

    Somit wäre die Frage, gibt es eine Möglichkeit dem User zwar keine Rechte an dem Server zu geben, allerdings ihn die Scripte ausführen zu lassen, welche während ihrer Laufzeit  administrative Rechte haben?

    Ich bin auch gerne an alternativ Lösungen Interessiert, sofern jemand eine Idee hat?

    Gruß,

    Joe


    • Bearbeitet Joe.D2 Montag, 4. Februar 2019 08:36
    Montag, 4. Februar 2019 08:36
    |

Antworten

  • Question
    Anmelden
    1
    Anmelden

    Interessante Diskussion... Dafür ist eigentlich das hier gedacht: https://docs.microsoft.com/de-de/powershell/jea/session-configurations

    Greetings/Grüße, Martin - https://mvp.microsoft.com/en-us/PublicProfile/5000017 Mal ein gutes Buch über GPOs lesen? - http://www.amazon.de/Windows-Server-2012--8-Gruppenrichtlinien/dp/3866456956 Good or bad GPOs? My blog - http://evilgpo.blogspot.com And if IT bothers me? Coke bottle design refreshment - http://sdrv.ms/14t35cq

    Montag, 4. Februar 2019 10:51
    |
  • Question
    Anmelden
    1
    Anmelden

    Moin,

    "admin, aber kein admin" - das riecht nach Schrödingers Katze ;-)

    Spaß beiseite, Du kannst Deine Skripte in geplante Tasks einpacken, die unter einem Admin-User laufen, und dem Agent-User lediglich das Recht geben, diese Tasks zu starten. Der manuelle Pflegeaufwand ist enorm, aber damit kann der Agent-User nichts ausführen, was seine Rechte nicht zulassen - außer Deiner Skripte eben.

    Alternativ könntest Du JEA einsetzen, und die Skripte würden sich mit dem Agent-User per Remoting zu einem anderen Endpoint verbinden, bei dem der Befehlssatz eingeschränkt ist, die Ausführung zulässiger Befehle aber mit Gottrechten geschieht.

    Evgenij Smirnov

    I work @ msg services ag, Berlin -> http://www.msg-services.de
    I blog (in German) @ http://it-pro-berlin.de
    my stuff in PSGallery --> https://www.powershellgallery.com/profiles/it-pro-berlin.de/
    Exchange User Group, Berlin -> https://exusg.de
    Windows Server User Group, Berlin -> http://www.winsvr-berlin.de
    Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.com

    In theory, there is no difference between theory and practice. In practice, there is.

    Montag, 4. Februar 2019 11:09
    |
  • Question
    Anmelden
    0
    Anmelden

    Du kannst hier z.b. sofern verfügbar auch ein Zerfikate für das PowerShell einsetzen und die Ausführung über GPO steuern. 

    oder aber Du machst im PowerShell ein User Context Wechsel ähnlich wie mit dem Befehl "Run as"

    aber hier ist immer das Riskio das hier die neue Session ebenfalls für "etwas" verwendet werden kann. 

    Please Mark This As Answer if it solved your issue
    Please Vote This As Helpful if it helps to solve your issue

    N 48° 8' 39.8419" E 11° 36' 1.3359"

    Klaus

    Montag, 4. Februar 2019 08:45
    |

Alle Antworten

  • Question
    Anmelden
    0
    Anmelden

    Du kannst hier z.b. sofern verfügbar auch ein Zerfikate für das PowerShell einsetzen und die Ausführung über GPO steuern. 

    oder aber Du machst im PowerShell ein User Context Wechsel ähnlich wie mit dem Befehl "Run as"

    aber hier ist immer das Riskio das hier die neue Session ebenfalls für "etwas" verwendet werden kann. 

    Please Mark This As Answer if it solved your issue
    Please Vote This As Helpful if it helps to solve your issue

    N 48° 8' 39.8419" E 11° 36' 1.3359"

    Klaus

    Montag, 4. Februar 2019 08:45
    |
  • Question
    Anmelden
    0
    Anmelden


    oder aber Du machst im PowerShell ein User Context Wechsel ähnlich wie mit dem Befehl "Run as"


    Daran hatte ich auch gedacht. Ich würde dann dem Benutzer des Agents lediglich ausführen Rechte auf die Powershell geben und auf das Script. Im Script würde dann stehen das die Session dann erst als "local system" geöffnet wird und dann die Befehle ausgeführt werden.

    Hattest du an so etwas gedacht?

    Könnte ich über die GPO, ausschließlich erlauben, das bestimmte Skripte bzw. Befehle zur Verfügung stehen, für den Benutzer?

    Montag, 4. Februar 2019 09:02
    |
  • Question
    Anmelden
    1
    Anmelden

    nun wie gesagt 

    sofern Du Zertifikate verwenden kannst hättest Du hierüber eine "kleine" Steuerung

    das Probleme ist das Du hier nicht etwas einschränken kannst weil Du i.d.R. nicht weißt welche Anwendungen im Hintergrund noch welche Aktivitäten ausführen..

    Ich denke es ist einfach eine Art "Whiteliste" zu führen und das während der Laufzeit zu prüfen. 

    Diese Liste obliegt Dir und damit dann auch die Verwaltung

    so nach dem freien Design

    führe aus was Du willst, prüfe aber vor dem Securtiy Wechsel ob das Skript zur Ausführung "freigegeben" ist. Erst kann kommt die Ausführung. 

    Klaus

    Montag, 4. Februar 2019 09:07
    |
  • Question
    Anmelden
    0
    Anmelden
    Wenn ich dich richtig verstanden habe, meinst du, der Benutzer selbst ist nicht eingeschränkt sondern es ist per "Whitlist" festgelt was er überhaupt ausführen darf an scripten. und sofern er das script ausführen darf, weil es in der Whitelist steht, würde durch das verwenden des Scriptes, erst der wechsel durchgeführt?
    Montag, 4. Februar 2019 09:12
    |
  • Question
    Anmelden
    0
    Anmelden

    ja das ist aus meiner Sicht die bessere  Lösung, 

    ich habe bei zig Kunden versucht die Ausführung zu verbieten und es gab immer wieder Probleme mit anderen Skripten etc. 

    sofern ich das richtig verstanden habe würde ich das über eine Positiv Liste regeln, alles was bekannt ist kann den Prozess verwenden, wenn es nicht bekannt ist geht es nicht und muss erst "freigegeben werden". 

    du hier auch auf Nagios oder ähnliches aufbauen, dort ist die Berechtigung bereits enthalten und es gibt zahlreiche Add-Ons. 

    oder eben von MS die Lösung (System Center Operation Manager) ist nicht ganz billig, aber richtig, richtig gut

    lg k. 

    Klaus

    Montag, 4. Februar 2019 09:28
    |
  • Question
    Anmelden
    0
    Anmelden

    Darf man Fragen wie oder wo du die Whitelist angelegt hast? Über die GPO?

    Es soll ja ausschließlich für diesen einen Dienstbenutzer gelten.

    Er wird sowieso im allgemeinen die powershell.exe öffnen können. Ich kann also Remote Befehle, die keine administrativen rechte erfordern dennoch von der Linux Maschine ausführen. Aber es minimiert schonmal den Schaden der bei missbrauch erzeugt wird, enorm.

    Montag, 4. Februar 2019 09:39
    |
  • Question
    Anmelden
    0
    Anmelden

    nein das ist über eine GPO nicht ohne weitere möglich

    direkt auf dem Server wo der Dienst läuft, 

    hier einfach im PowerShell ein Call back mit dem Namen einfügen

    ich würde das ganze aus Gründen der Sicherheit verschlüsselt übertragen. 

    sprich Modul a wird zu GUID …. , Modul b wird zur GUID 

    auf der Server Seite liegt dann der Modul Name, die GUID und der CRC Wert

    damit kann keiner an der Funktion was ändern weil der CRC Wert sich sofort ändert. 

    Klaus

    Montag, 4. Februar 2019 09:52
    |
  • Question
    Anmelden
    0
    Anmelden

    Ich stehe grade bei der Logik etwas auf dem Schlauch. Ich versuche das mal etwas zu verbildlichen wie das in meinem Verständnis verläuft.

    Derzeitiger Weg:

    Linux Server --->sendet Ausführungsbefehl powershell.exe + Info mit welchem script und wo es liegt ---> Agent auf dem Client öffnet die Powershell mit seinen Rechten (ab hier kann jeder befehl übermittelt werden vom Linux server aus) ---> Script wird aufgerufen

    Neuer weg:

    Linux Server --->sendet Ausführungsbefehl powershell.exe + Info mit welchem script und wo es liegt ---> Agent auf dem Client öffnet die Powershell mit seinen Rechten (ab hier kann jeder befehl übermittelt werden vom Linux server aus) ---> Script wird aufgerufen was per CRC Checksumme prüft, ob der folge Befehl aufgrund der CRC Checksumme, derjenige ist, den ich will ---> der Befehl wird ausgeführt, Rechte werden angehoben und der admin Befehel ausgeführt

    Hab ich das richtig Dargestellt?

    • Bearbeitet Joe.D2 Montag, 4. Februar 2019 10:24
    Montag, 4. Februar 2019 10:23
    |
  • Question
    Anmelden
    0
    Anmelden

    ja so würde ich das auch machen

    wenn Du das ganz komfortable machen willst

    Linux Server ruft PowerShell script auf

    PS Script prüft zur Laufzeit die Umgebung und die vorgegenen Info ab 

    und nur wenn alles ok ist startet der Admin Part.

    hier kannst Du evtl sogar gegen eine MS-SQL DB oder Webservices laufen 

    und dir dort dann über Secure Data User, PW abholen. 

    Klaus

    Montag, 4. Februar 2019 10:46
    |
  • Question
    Anmelden
    1
    Anmelden

    Interessante Diskussion... Dafür ist eigentlich das hier gedacht: https://docs.microsoft.com/de-de/powershell/jea/session-configurations

    Greetings/Grüße, Martin - https://mvp.microsoft.com/en-us/PublicProfile/5000017 Mal ein gutes Buch über GPOs lesen? - http://www.amazon.de/Windows-Server-2012--8-Gruppenrichtlinien/dp/3866456956 Good or bad GPOs? My blog - http://evilgpo.blogspot.com And if IT bothers me? Coke bottle design refreshment - http://sdrv.ms/14t35cq

    Montag, 4. Februar 2019 10:51
    |
  • Question
    Anmelden
    0
    Anmelden

    ich hab überlegt dafür eine art Service Admin anzulegen oder einen Benutzer mit rechten auf das was er dann braucht. und die Passwortinformationen erstmal verschlüsselt in einer Passwortdatei irgendwo zu hinterlegen mit einem Leserecht für den Benutzer. Während der Laufzeit wird es dann eingelesen. Wäre jetzt für meine Testumgebung die einfachste möglichkeit, da kein SQL Server o.ä vorhanden ist.

    Was den Komfort angeht. Dadurch das jeder Check ein eigenes Script wäre, würde das bedeuten das ich die Checksummen irgendwo hinterlegen muss, weil diese sich ja für jedes Script ändern würde. Hast du da eine Idee wie ich das komfortable lösen könnte?

    Montag, 4. Februar 2019 10:54
    |
  • Question
    Anmelden
    1
    Anmelden

    Moin,

    "admin, aber kein admin" - das riecht nach Schrödingers Katze ;-)

    Spaß beiseite, Du kannst Deine Skripte in geplante Tasks einpacken, die unter einem Admin-User laufen, und dem Agent-User lediglich das Recht geben, diese Tasks zu starten. Der manuelle Pflegeaufwand ist enorm, aber damit kann der Agent-User nichts ausführen, was seine Rechte nicht zulassen - außer Deiner Skripte eben.

    Alternativ könntest Du JEA einsetzen, und die Skripte würden sich mit dem Agent-User per Remoting zu einem anderen Endpoint verbinden, bei dem der Befehlssatz eingeschränkt ist, die Ausführung zulässiger Befehle aber mit Gottrechten geschieht.

    Evgenij Smirnov

    I work @ msg services ag, Berlin -> http://www.msg-services.de
    I blog (in German) @ http://it-pro-berlin.de
    my stuff in PSGallery --> https://www.powershellgallery.com/profiles/it-pro-berlin.de/
    Exchange User Group, Berlin -> https://exusg.de
    Windows Server User Group, Berlin -> http://www.winsvr-berlin.de
    Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.com

    In theory, there is no difference between theory and practice. In practice, there is.

    Montag, 4. Februar 2019 11:09
    |
  • Question
    Anmelden
    0
    Anmelden

    nun dann hast du aber immer noch das Problem mit dem der User kann dann alles ausführen ohne Kontrolle - oder habe ich das eben falsch gelesen ? 


    Klaus

    Montag, 4. Februar 2019 11:25
    |
  • Question
    Anmelden
    0
    Anmelden

    Danke für die vielen Ideen.

    Also bei dem Monitoring Tool was ich grade teste, handelt es sich um Icinga.

    Allerdings vertraue ich dem nicht so weit, als das ich meinem Server in einer produktiven Umgebungen die Rechte einräumen würde, Befehle auf den Servern auszuführen die nicht notwendig sind.

    Das mit den Tasks hab ich am Anfang mal im Sinn gehabt. Das Problem wird es sein, wie du schon sagtest, das ganze zu Pflegen und am Anfang aufzubauen.


    • Bearbeitet Joe.D2 Montag, 4. Februar 2019 11:31
    Montag, 4. Februar 2019 11:31
    |
  • Question
    Anmelden
    0
    Anmelden

    nun dann hast du aber immer noch das Problem mit dem der User kann dann alles ausführen ohne Kontrolle - oder habe ich das eben falsch gelesen ? 


    Klaus

    Der Agent wird standardgemäß mit NT\Netzdienst angemeldet. D.h. der Server Kann zwar alles auf dem Clienten ausführen, aber eben nur im Rahmen der Rechte von dem Dienstkonto. Das werde ich auch wohl nicht weiter einschränken können. Aber soweit ich weis ist dieser Benutzer nicht in der Lage administrative Tätigkeiten auszuführen.

    Es reicht aber um die Powershell mit dem Script zu öffnen was die Rechte für den Zeitraum anhebt.

    So habe ich das gemeint

    Montag, 4. Februar 2019 11:36
    |
  • Question
    Anmelden
    0
    Anmelden

    die Frage galt mehr Martin sorry Joe. 

    Klaus

    Montag, 4. Februar 2019 13:47
    |
  • Question
    Anmelden
    0
    Anmelden

    nun dann hast du aber immer noch das Problem mit dem der User kann dann alles ausführen ohne Kontrolle - oder habe ich das eben falsch gelesen ? 

    Nein,

    bei einem JEA Endpoint kannst Du die Befehle begrenzen, die ausgeführt werden können.

    Evgenij Smirnov

    I work @ msg services ag, Berlin -> http://www.msg-services.de
    I blog (in German) @ http://it-pro-berlin.de
    my stuff in PSGallery --> https://www.powershellgallery.com/profiles/it-pro-berlin.de/
    Exchange User Group, Berlin -> https://exusg.de
    Windows Server User Group, Berlin -> http://www.winsvr-berlin.de
    Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.com

    In theory, there is no difference between theory and practice. In practice, there is.

    Montag, 4. Februar 2019 18:05
    |
  • Question
    Anmelden
    0
    Anmelden
    ...und die können dann halt ausgeführt werden, ja. Das ist die "Angst" des TO :-))

    Greetings/Grüße, Martin - https://mvp.microsoft.com/en-us/PublicProfile/5000017 Mal ein gutes Buch über GPOs lesen? - http://www.amazon.de/Windows-Server-2012--8-Gruppenrichtlinien/dp/3866456956 Good or bad GPOs? My blog - http://evilgpo.blogspot.com And if IT bothers me? Coke bottle design refreshment - http://sdrv.ms/14t35cq

    Montag, 4. Februar 2019 18:26
    |
  • Question
    Anmelden
    0
    Anmelden

    Erstmal Danke an euch alle, da führen scheinbar mehrere Wege nach Rom!

    Und ich denke das hier genug Lösungsansätze gekommen sind,das ich da einen für mich optimalen Weg finden werde.

    Dienstag, 5. Februar 2019 10:06
    |
  • Question
    Anmelden
    0
    Anmelden

    Ich hab jetzt mal auf die schnelle versucht in mein Script einen kleinen Userwechsel einzubauen, um zu testen ob das alle so läuft wie ich mir das Vorstelle, bevor ich mir größeren Aufwand mache.

    Leider läuft das nicht so wie ich mir das vorgestellt habe, hier die Befehle, evtl kann mir jmd sagen wo es hängt:

    $Pass = "passwort"
    $user = "domain\user"

    $SecurePassword = $Pass | ConvertTo-SecureString -AsPlainText -Force
    $Credential = New-Object System.Management.Automation.PSCredential $user, $SecurePassword

    Wenn ich jetzt versuche:

    Start-Process powershell -Verb runAS -Credential $Credential

    zu Benutzen, erhalte ich z.B. Folgende Meldung:

    Start-Process : Der Parametersatz kann mit den angegebenen benannten Parametern nicht aufgelöst werden
    In Zeile:1 Zeichen:1
    + Start-Process powershell -Verb runAS -Credential $Credential
    + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        + CategoryInfo          : InvalidArgument: (:) [Start-Process], ParameterBindingException
        + FullyQualifiedErrorId : AmbiguousParameterSet,Microsoft.PowerShell.Commands.StartProcessCommand

    Wenn ich den Invoke-Command nehme erhalte ich ein Zugriff verweigert und bei ein RunAs bekomm ich Benutzername und PW falsch. Die stimmen allerdings auffallend.

    Dienstag, 5. Februar 2019 10:56
    |
  • Question
    Anmelden
    0
    Anmelden 
    $username = "username" 
$password = "password"
$startWithElevatedRights = "notepad"

$credentials = New-Object System.Management.Automation.PSCredential -ArgumentList @($username,(ConvertTo-SecureString -String $password -AsPlainText -Force))
$ps = Start-Process -PassThru -FilePath powershell -Credential $credentials -ArgumentList '-noprofile -command &{Start-Process ',  $startWithElevatedRights, ' -Wait -verb runas}'

$ps.WaitForExit()

    Please Mark This As Answer if it solved your issue
    Please Vote This As Helpful if it helps to solve your issue

    N 48° 8' 39.8419" E 11° 36' 1.3359"

    Klaus



    Dienstag, 5. Februar 2019 11:31
    |
  • Question
    Anmelden
    0
    Anmelden

    klappt bedingt.

    Ergebnis ist, das er noch mal mit dem Passwortfenster kommt?!. Wo keine Zugangsdaten drin stehen. Wenn ich die dann Manuell eingebe, lande ich allerdings in der richtigen Shell

    Dienstag, 5. Februar 2019 14:39
    |
  • Question
    Anmelden
    0
    Anmelden

    das ist kein Passwort Fenster sondern das Fenster der UAC weil Du mit Admin Rechte startest. das kommt immer wenn Du "erhöhte Rechte" hast und ein Process starten willst. 

    Klaus

    Dienstag, 5. Februar 2019 17:40
    |
  • Question
    Anmelden
    0
    Anmelden

    Das es das UAC Fenster ist habe ich bereits herausgefunden. Trotzdem vielen Dank.

    Dienstag, 5. Februar 2019 23:09
    |
  • Question
    Anmelden
    0
    Anmelden

    Kleiner Nachtrag: Mir scheint, es ist gar nicht mal so leicht die UAC zu umgehen. Sollte ich es irgendwie hin bekommen, werde ich das Ergebnis hier posten.

    Danke an alle!

    Mittwoch, 6. Februar 2019 06:16
    |
  • Question
    Anmelden
    0
    Anmelden

    das hier sollte Dir ein wenig helfen 

    https://ss64.com/ps/syntax-elevate.html

    aber die UAC hat schon ihren Sinn. ;-)

    Klaus

    Mittwoch, 6. Februar 2019 10:06
    |
  • Question
    Anmelden
    0
    Anmelden

    > Mir scheint, es ist gar nicht mal so leicht die UAC zu umgehen

    Davon kann man auch nur abraten. Wenn du die Tasks automatisierst ohne Benutzeraktion (AufgabenPlaung, GPO), stört dich die UAC nicht.
    Wenn der Nutzer aber Eingriffsmöglichkeiten hat, solltest du auf keinen  Fall versuchen die UAC zu umgehen. Das wäre grob fahrlässig.
    Und warum auch? Benutzer sind das UAC-Popup gewöhnt.

    Blog: http://www.bytecookie.de

    Powershell Code Manager v6: Link
    (u.a. Codesnippets verwalten + komplexe Scripte graphisch darstellen)

    Hilf mit und markiere hilfreiche Beiträge mit dem "Abstimmen"-Button (links) und Beiträge die eine Frage von dir beantwortet haben, als "Antwort" (unten).
    Warum das Ganze? Hier gibts die Antwort.

    Mittwoch, 6. Februar 2019 11:31
    |
    Moderator
  • Question
    Anmelden
    0
    Anmelden

    Da gebe ich dich recht.

    Allerdings handelt es sich hier um einen Dienst Benutzer eines Monitoring Agenten. Somit ist es kein Mensch, der das PopUp anklicken kann.

    Das ganze über einen Task laufen zu lassen, ist wohl die sicherste Lösung, allerdings muss ich hier auch einen Weg finden, die Ergebnisse an den Agenten zurück zu schicken, via Logfile etc.

    Und mit die UAC umgehen, meine ich nicht sie zu deaktivieren oder ähnliches. So etwas wie mit einem Task meine ich, wenn ich von umgehen spreche.

    Montag, 11. Februar 2019 09:17
    |
  • Question
    Anmelden
    0
    Anmelden

    > allerdings muss ich hier auch einen Weg finden, die Ergebnisse an den Agenten zurück zu schicken, via Logfile etc.

    Meiner Ansicht nach ist das der falsche Weg. :) Ernsthaft: du versucht da über Haken und Umwege etwas sicherer zu machen was einfach schlecht designt ist. Das Problem dabei ist oft, das wenn immer du ein Problem gelöst hast, poppt ein anderes auf. Ich würde mir die Zeit und damit Geld sparen und nach einer sicheren Monitoring-Lösung ausschau halten die bereits bietet was du brauchst. 

     

    Blog: http://www.bytecookie.de

    Powershell Code Manager v6: Link
    (u.a. Codesnippets verwalten + komplexe Scripte graphisch darstellen)

    Hilf mit und markiere hilfreiche Beiträge mit dem "Abstimmen"-Button (links) und Beiträge die eine Frage von dir beantwortet haben, als "Antwort" (unten).
    Warum das Ganze? Hier gibts die Antwort.


    Montag, 11. Februar 2019 10:26
    |
    Moderator