none
mit erweiterten (elevated) Benutzerrechten Code und Programme ausführen RRS feed

  • Allgemeine Diskussion

  • Hallo
    Habe aktuell folgendes Problem. Muss demnächst ein Rollout von massenweise Windows 7 Pcs machen. Alle Pcs melden sich über Samba-Domänen am Netz an (d.h. kein Active Directory, GPO, SMS usw.)
    Sobald sich die Benuter mit Bentuzerrechten in der Samba-Domäne anmelden, muss ich die Möglichkeit haben, mit "administrativen Rechten" und ohne Interaktivitäte von Seiten des Benutzers, Software zu installieren, Registry-Keys zu schreiben usw und so fort und das mit uneingeschränkten Rechten.
    Die Powershell habe ich vor kurzem entdeckt und sie scheint wie geschaffen für mich.
    Mein Problem: Ich schaffe es, mit Powershell mit anderem administrativem Konto eine Installation anzuschieben, leider scheitert die Installation dann wegen der UAC von Windows (weil obwohl lokale Administratoren Rechte, wegen der UAC, trotzdem nur eingeschränkte Rechte, daher müsste ich irgendwie noch Das "Elevate"- Verb "runas" nachschieben. Das schaffe ich nicht. "RunAs" bleibt bei Angabe von einem Fremdkonto ohne Wirkung
    Alernativ habe ich die UAC für Administratoren-Konten deaktiviert. Dann würde die Sache rund laufen, allerdings ist dann der große Haken: Möchte der lokale Benutzer vor Ort kurzfristig Administratoren-Rechte für die Installation eines Programmes erlangen, funktioniert die "Run as Administrator" Methode nicht mehr.

    Hier mein Skript exec.ps1:

    param (
            [string]$command=$(throw("Bitte mindestens den Kommand-Befehl angeben (optional: arg -user -dom -scrdir")),
            [string]$arg="",
            [string]$user="install",
            [string]$dom=$false,
            [string]$scrdir="c:\sgv\scripts"
          )

    if ($dom -eq $false) {$dom=$env:computername}
    $passfile="$scrdir\pass\zugang.s"
    $cred=(& $scrdir\pass\passdec.ps1 $passfile)
    $passenc=""
    $cred.username

    function launchprog
    {
            $lobj=new-object System.Diagnostics.ProcessStartInfo
            $lobj.Username=$user
            $lobj.Password=$cred.password
            $lobj.Filename=$command
            $lobj.Arguments=$arg
            $lobj.domain=$dom
            $lobj.Verb="RunAs"
            $lobj.WorkingDirectory=$scrdir
            $lobj.LoadUserProfile=$true
            $lobj.UseShellExecute=$false
            [system.Diagnostics.Process]::Start($lobj)
    }

    launchprog

    Beispiel: powershel -command .\exec.ps1 c:\windows\system32\notepad.exe c:\windows\system32\drivers\etc\hosts ... müsste mir die Datei Hosts ändern lassen, aber nada

    Das Problem hier eben: Verb="Runas" in zusammenhang mit einem Benutzerkonto (hier Benutzer install ist lokaler Administrator) scheint keine Wirkung zu zeigen.
    Ist das vielleicht ein Bug? Wahrscheinlicher ist, dass ich etwas nicht richtig gemacht habe

    Habt Ihr vielleicht einen Tip?
    Donnerstag, 11. Februar 2010 18:36

Alle Antworten

  • Hallo HubertK,
    so wie ich das sehe wird Dein Startinfo Object vermutlich nicht mit dem Passwort bestückt. Du liest es aus der Datei zugang.s als string ein, oder?
    Die Password Eigenschaft des Startinfo-Objektes erwaret ein Object des Typs system.security.securestring.
    Probier mal das Kennwort im Script zu hinterlegen (nur für Testzwecke!) und in ein "SecureString" zu konvertieren bevor Du es dem Startinfo-Objekt zuweist:

    $Password = ConvertTo-SecureString -AsPlainText "password" -Force

    VG
    Bernd
    Freitag, 12. Februar 2010 14:16
  • Hallo Bernd
    Danke für Deine Infos

    Doch, das Passwort habe ich bloß cryptiert im Base64-Formate in zugang.s hinterlegt (da Passwörter im SecureString-Format gehasht und mit anderen Benutzerkonten, Clients usw. dann plötzlich nicht mehr funktionieren). passdec.ps1 macht dann die Arbeit, den String in SecureString-Objekt umzuwandeln.
    Das Problem scheint wirklich zu sein, dass Verb "Runas" nicht mit mitgegebenen Kredentialien funktioniert.

    Ich habe mich noch weiter damit beschäftigt, und habe dann ein Script endeckt, das einen anderen Anatz verfolgt, nämlich das Comp. Modell mit dem Shell.Application Interface.

    function Run-Elevated ($param)
    {
      $sh = new-object -com 'Shell.Application'
      $sh.ShellExecute('powershell', "-Command $param", '', 'runas')
    }

    Mein Skript kombiniert mit diesem Scriptlet brachte mir fast den gewünschten Effekt. Ich kann Kommandos und Installationen aufrufen. Allerdings muss der Benutzer  Bestätigungs-Prompts (für die erweiterten Rechte) interaktiv nachschieben.

    Und ich habe ein elevation.cmd, elevation.vbs der "Elevation Powertoys"-Tools gefunden. Diese verfolgen genau auch den shell.application Ansatz und können mit meinem Skript gut kombiniert werden. 
     
    Jetzt habe ich gerade entdeckt, dass bei Powershell 2.0 ein cmdlet "start-process" integriert wurde, das ich noch ausprobieren muss, aber es lehnt sich mit Sicherheit an .net processStartInfo an, daher erwarte ich wenig Hilfe.

    Trotzdem werde ich damit leben können. Alternativ muss ich halt die UAC für Administratoren deaktivieren.

    Es ist richtig, das Microsoft viel in Sicherheit investiert hat, aber das darf nicht auf Kosten der Automatisierung der administrativen Arbeit des Betriebssystems gehen. Außerdem hat die Klicko-Mania bei Vista/7 unerträglich und extrem zugenommen. Meine Sehnen bedanken sich ganz herzlich bei Micrsosoft. Persönlich bin ich schon lange auf Linux ausgewichen. Richtig: Meine Sehnen haben Vorrang
    Samstag, 13. Februar 2010 11:10
  • OK, die Zeile mit dem decrypt hatte ich glatt überlesen. An diesem Code wäre ich aber interessiert :-)
    Ich kann's grad auf die schnelle nicht testen, aber hast Du's mit $lobj.UseShellExecute=$true mal probiert?

    VG
    Bernd
    • Bearbeitet Bernd W Sonntag, 14. Februar 2010 07:43 Wortfehler
    Samstag, 13. Februar 2010 13:50
  • Ich hab's mir unter Window 7 noch mal angeschaut.
    Das Problem ist immer die UAC und dass es unter anderer Identität generell nicht tut.

    Mit dem hier....

    $proc = New-Object system.Diagnostics.ProcessStartInfo
    $proc.FileName = 'powershell.exe'
    $proc.Verb = 'runas'
    $Proc.UseShellExecute = $true
    [system.Diagnostics.Process]::Start($proc)

    ... kann  der angemeldete Benutzer, wenn er Admin ist, einen Prozess, in dem Fall die Powershell, mit Admin Rechten starten.
    Wenn die UAC aktiv ist fragt W7 ob man das wirklich möchte.

    Das starten eines Prozesses unter anderer Identität scheint aber generell unter W7 nicht möglich zu sein - auch mit start-process nicht.
    Echt übel, ich brauche was ähnliches in absehbarer Zeit nämlich auch.... .
    Samstag, 13. Februar 2010 16:19
  • HubertK:

    > Alernativ habe ich die UAC für Administratoren-Konten deaktiviert

    Auf welche Weise, wenn man fragen darf?

    hpm
    Sonntag, 14. Februar 2010 00:46
  • Hallo Bernd

    Hier der Code für passdec.ps1
    Sicher gibt es vermutlich bessere Methoden zum crypten. Die Securestring-Methode von Microsoft wäre sehr geignet, wenn sie nicht einem Sitzungcode oder so was ähnliches unterliegt und ständig variert.

    param ($passfile=$(throw "Bitte das verschlüsselte Passwortfile angeben"))

    # wandelt den im angegeben File Base64-codierten Text in Klartext um
     
    $pass64=get-content($passfile)
    $pass = [Text.Encoding]::unicode.getString([convert]::FromBase64String($pass64))
    $passsec=$pass|convertTo-securestring -asPlainText -force
    $global:cred=new-object system.management.automation.PsCredential -argumentlist "install",$passsec
    $pass=$false
    $cred


    Hier noch die Methode zum encrypten:

    param ($passfile=$(throw "Bitte Passwortfile für die verschlüsselte Ausgabe angeben"),$passwort="Password")

    # passenc nimmt das eigegebene Kennwort als sicheren String auf und
    # wandelt diesen in Cleartext
    # die restliche Routine wandelt Cleartext in Base64
     
    function passenc($prompt)
    {
      $password = Read-Host -AsSecureString $prompt 
      $BSTR = [System.Runtime.InteropServices.marshal]::SecureStringToBSTR($password)
      $password = [System.Runtime.InteropServices.marshal]::PtrToStringAuto($BSTR)
      [System.Runtime.InteropServices.Marshal]::ZeroFreeBSTR($BSTR)
      return $password
    }

    $pass = passenc $passwort
    $pass64 = [system.Convert]::ToBase64String([System.Text.Encoding]::unicode.getbytes($pass))
    $pass = $false
    out-file $passfile -inputObject $pass64
    Montag, 15. Februar 2010 16:05
  • Hallo Hans-Peter

    Führe gpedit.msc aus
    Unter Computerkonfiguration - Windows Einstellungen - Sicherheitseinstellungen - Lokale Richtlinien - Sicherheitsoptionen
    Benutzerkontensteuerung: Alle Administratoren im Administratorbestätigungsmodus ausführen deaktivieren

    Vorteil: Als administrativer Benutzer hat man effektiv alle Administratorenrechte (also kein RunAs erforderlich). Scripts laufen dann problemlos
    Nachteil: Als Benutzer kann ich mich nicht mehr als Admin authentifizieren, sprich Strg-Shift Enter <befehl> funktioniert nicht mehr

    Also ein klassisches sudo wie in Linux habe ich in Windows nicht zum laufen gebracht. Vielleicht gibt es eine versteckte Methode.
    Ein bischen scheint mir das schon alles paranoid.

    Montag, 15. Februar 2010 16:26
  • Hallo Bernd

    Also bei mir hat es funktioniert, aber eben nur mit interaktivem Bestätigungspromt (nicht ideal) und nicht gerade elegant:
    powershell -command c:\sgv\scripts\exec.ps1 powershell '-command c:\sgv\scripts\elevate.ps1 c:\windows\system32\notepad.exe c:\windows\system32\drivers\etc\hosts'

    Erklärung: exec.ps1 wie im ersten Tread beschrieben
    Inhalt von elevate.ps1:

    param ($p)
    function Elevate ($sc)

    {
      # TODO: make -NoExit a parameter
      # TODO: just open PS (no -Command parameter) if $sb -eq ''
      $sh = new-object -com 'Shell.Application'
      $sh.ShellExecute('powershell', "-Command $sc", '', 'runas')
    }
    elevate $p

    Alternative bessere Methode: mit Elevation Powertoys (im Internet zum Herunterladen http://technet.microsoft.com/en-us/magazine/2008.06.elevation.aspx)
    dazu elevate.cmd und elevate.vbs nach c:\windows\system32 kopieren:
    powershell -command c:\sgv\scripts\exec.ps1 elevate.cmd 'notepad.exe c:\windows\system32\drivers\etc\hosts'
    Montag, 15. Februar 2010 16:46
  • HubertK:

    > Führe gpedit.msc aus
    > Unter Computerkonfiguration - Windows Einstellungen - Sicherheitseinstellungen - Lokale
    > Richtlinien - Sicherheitsoptionen
    > Benutzerkontensteuerung: Alle Administratoren im Administratorbestätigungsmodus ausführen
    > deaktivieren

    Ach so, das kenne ich. Ich dachte, du hättest da etwas anderes gebastelt.

    > Vorteil: Als administrativer Benutzer hat man effektiv alle Administratorenrechte (also kein RunAs
    > erforderlich). Scripts laufen dann problemlos

    Das ist ein kleiner Irrtum. Admin-Konten haben danach weiterhin das
    User-Token, Programme laufen weiterhin mit eingeschränkten Rechten, auch der
    IE bleibt im geschützten Modus. Es wird nur eine automatische Erhöhung
    durchgeführt, wenn ein Programm Adminrechte anfordert.

    > Nachteil: Als Benutzer kann ich mich nicht mehr als Admin authentifizieren, sprich Strg-Shift Enter
    > <befehl> funktioniert nicht mehr

    Doch, in Standardkonten funktioniert danach weiterhin "als Admin ausführen".
    Wenn das bei dir nicht so ist, ist dein Windows kaputt oder du hast UAC
    deaktiviert. Mit deiner obigen Maßnahme wird UAC jedenfalls NICHT
    deaktiviert.

    > Also ein klassisches sudo wie in Linux habe ich in Windows nicht zum laufen gebracht. Vielleicht
    > gibt es eine versteckte Methode.
    > Ein bischen scheint mir das schon alles paranoid.

    Da gibt's auch diverse Möglichkeiten. Man kann Programme via schtasks.exe
    mit erhöhten Rechten starten oder es auch über den WSH skripten...
    Sudo braucht's nicht wirklich.

    hpm
    Dienstag, 16. Februar 2010 14:02
  • Hallo Hans-Peter,
    Du schreibst "Da gibt's auch diverse Möglichkeiten. Man kann Programme via schtasks.exe
    mit erhöhten Rechten starten oder es auch über den WSH skripten..."

    Hast Du eine konkrete Lösung für WSH?
    Wenn's mit WSH machbar ist geht's auch mit Powershell.

    VG
    Bernd
    Dienstag, 16. Februar 2010 21:12
  • Bernd W:

    > Hast Du eine konkrete Lösung für WSH?
    > Wenn's mit WSH machbar ist geht's auch mit Powershell.

    Ich starte manche Skripte oder Programme im Kontext des vordefinierten
    Admin-Kontos, und zwar via runas. Das Passwort wird einfach mit Sendkeys
    übergeben und das Skript dann mit dem Script-Encoder als *vbe gespeichert.

    hpm
    Dienstag, 16. Februar 2010 22:03
  • Hans-Peter Matthess:

    > Das ist ein kleiner Irrtum.

    Aber von mir. Ich hatte die Richtlinie mit einer anderen verwechselt.
    Damit wird UAC natürlich komplett abgeschaltet.

    hpm
    Dienstag, 16. Februar 2010 22:04