none
Non-elevated Laufwerkseinbindung aus elevated-Prozess heraus starten

    Allgemeine Diskussion

  • Howdi,

    ich gehe demnächst die Wand hoch und hoffe daher stark, dass hier jemand eine tolle Idee hat.

    Ausgangsbasis:
    Wir loggen uns als Standarduser auf unseren administrativen Maschinen ein.
    Dann entpackt eine exe, die "als Administrator" (sprich elevated) gestartet wird, eine hta-Datei nach %appdata%\local\temp und führt diese aus.

    Es handelt sich hierbei um ein administratives Tool, welches über JavaScript (und sehr wenig VBS, quasi nur für LDAP-Abfragen) alle möglichen Dinge realisiert.

    Das Problem ist meines Erachtens nach aber ganz unabhängig von der [exe[hta]]-Verschachtelung.

    Was ich wieso und weshalb vorhabe: Öffne ich von unseren administrativen Geräten aus ein Share, indem ich einfach den Pfad (bspw. \\%target%\d$) angebe, so erscheint die UAC. Vollkommen korrekt, schließlich hat nur der administrative Account Zugriffsrechte, und wir starten ja von einem eingeschränkten User aus.
    (Auf wenigen Geräten erscheint die UAC gar nicht, sondern es gibt direkt nen Access-Error. Das ist aber nicht die Norm und kann meines Erachtens nach daher ignoriert werden)

    Ich möchte das ganze aber ohne lästige UAC realisieren, indem ich das nötige Share einfach bei Bedarf über eine Function einbinde. Über "net use /USER" bin ich auch quasi sofort zum gewünschten Ergebnis gekommen.

    Problem: Das funktioniert nur, wenn es non-elevated ausgeführt wird. Sobald ich es direkt aus dem Tool ausführen lasse ist es aufgrund der Verkettung elevated und das Share ist nur für den Adminaccount verfügbar - was mir nichts bringt, da dieser keine aktive GUI hat.

    Lösungsversuch 1:
    "Gut", dachte ich mir, "ich kann net use bestimmt auch irgendwie non-elevated anwerfen und wieder /USER übergeben". Aber weit gefehlt: Es will einfach nicht.
    Ich habe bereits RunAs und PsExec versucht, aber keinen Erfolg gehabt.

    1) runas /user:domain\noadmin "powershell \"$net = new-object -ComObject WScript.Network ; $net.MapNetworkDrive(\"j:\", \"\\target\d$\", $false, \"domain\admin\", \"password\")\""
    
    2) PsExec.exe -u "domain\noadmin" -p "password" c:\windows\system32\WindowsPowerShell\v1.0\powershell.exe "$net = new-object -ComObject WScript.Network ; $net.MapNetworkDrive(\"j:\", \"\\target\d$\", $false, \"domain\admin\", \"password\")"

    Beide Male erscheint das Laufwerk nirgendwo, nichtmal in der shell. (Führe ich den Powershell-Befehl seperat aus klappt es natürlich sofort).

    Auch wenn ich statt über psh zu gehen direkt "net use" benutze kriege ich das Laufwerk maximal unterm Admin eingebunden (also nur via Shell bedienbar).

    Lösungsversuch 2:
    Irgendwann dachte ich nur noch; "To hell with it. Starte ich halt den Explorer als Admin und erfreue mich der Laufwerke." Weit gefehlt. Der Explorer lässt sich nicht als Admin starten.

    Klar, ich kann ihn "als Administrator" starten und meine Daten in die UAC eingeben, das ändert aber nichts daran dass es nur ein Child der bereits vorhandenen explorer.exe wird, die meine GUI managed. Und diese hat ja keine Rechte...

    Lustiges Detail am Rande: Schiesse ich über den Taskmanager meine explorer.exe ab und launche die neue direkt als Admin, so erscheint nur folgende FM:

    Möglicher Workaround:
    Alternativen Explorer (bspw. TotalCommander) als Admin starten. Wir sind allerdings wenig motiviert wegen einer solch lächerlichen Anforderung auf jedem Client (denn wir rufen das Programm auch von diesen ausgehend auf) einen seperaten Dateiexplorer zu hinterlegen/installieren.

    Daher die Frage:
    Ist eine derartige Konstellation mit Windows-Boardmitteln einfach nicht zu lösen ?
    Stelle ich mich einfach nur zu blöd an ? (zu kompliziert, nicht kompliziert genug, whatever)

    Für jeglichen Input wäre ich dankbar :)

    Gruß

    Oliver

    Anhang:

    Freitag, 25. Januar 2013 09:27

Alle Antworten

  •  
    > Wir loggen uns als Standarduser auf unseren administrativen Maschinen ein.
    > Dann entpackt eine exe, die "als Administrator" (sprich elevated)
    > gestartet wird, eine hta-Datei nach %appdata%\local\temp und führt
    > diese aus.
    >
     
    Ist dieses "als Administrator" ein anderer Account (anderer User) oder
    nur elevated?
     
    >
    > *Was ich wieso und weshalb vorhabe:* Öffne ich von unseren
    > administrativen Geräten aus ein Share, indem ich einfach den Pfad
    > (bspw. \\%target%\d$) angebe, so erscheint die UAC. Vollkommen
    > korrekt, schließlich hat nur der administrative Account
    > Zugriffsrechte, und wir starten ja von einem eingeschränkten User aus.
    >
     
    Warum sollte beim Öffnen eines Shares eine UAC-Abfrage kommen??? Das ist
    doch höchstens ein Credential-Dialog, oder?
     
    > *Problem:* Das funktioniert nur, wenn es non-elevated ausgeführt wird.
    > Sobald ich es direkt aus dem Tool ausführen lasse ist es aufgrund der
    > Verkettung elevated und das Share ist nur für den Adminaccount
    > verfügbar - was mir nichts bringt, da dieser keine aktive GUI hat.
    >
     
    EnableLinkedConnections kennst Du?
     
    > Irgendwann dachte ich nur noch; "To hell with it. Starte ich halt den
    > Explorer als Admin und erfreue mich der Laufwerke." Weit gefehlt. Der
    > Explorer lässt sich nicht als Admin starten.
     
    Doch. Aber nur, wenn man vorher ein wenig in der Registry "fummelt":
    Explorer Elevated Unelevated Factory.
     
    mfg Martin
     

    NO THEY ARE NOT EVIL, if you know what you are doing: Good or bad GPOs?
    Wenn meine Antwort hilfreich war, freue ich mich über eine Bewertung! If my answer was helpful, I'm glad about a rating!
    Freitag, 25. Januar 2013 12:45
  • Ist dieses "als Administrator" ein anderer Account (anderer User) oder nur elevated?

    Ein separater Account (Die Bezeichnung ist quasi "*Personalnummer*" und "*Personalnummer*a" <- mit a beim administrativen Account)

    Warum sollte beim Öffnen eines Shares eine UAC-Abfrage kommen??? Das ist doch höchstens ein Credential-Dialog, oder?

    Args. Sorry. Jep. Wir gehen zu selten über ein Share, daher hat mein Kopf das Design nur mit der UAC verbunden. Ist eine normale Credential-Abfrage.

    EnableLinkedConnections kennst Du?

    Ich meine ich wäre letzte Woche schon drüber gestolpert und es hätte nicht funktioniert. Ich schau aber nochmal.

    Doch. Aber nur, wenn man vorher ein wenig in der Registry "fummelt": Explorer Elevated Unelevated Factory.

    Nett. Das war mir bisher nicht untergekommen. Ich wühl mich mal durch.

    Schonmal danke, ich melde mich später nochmal ;)

    Gruß

    Oliver


    • Bearbeitet buggrabber Montag, 28. Januar 2013 08:38
    Montag, 28. Januar 2013 08:37
  •  
    > Ich wühl mich mal durch.
     
    Viel Spaß dabei :-D
     

    NO THEY ARE NOT EVIL, if you know what you are doing: Good or bad GPOs?
    Wenn meine Antwort hilfreich war, freue ich mich über eine Bewertung! If my answer was helpful, I'm glad about a rating!
    Montag, 28. Januar 2013 11:48
  • Howdi,

    jein.

    Ja im Sinne von "ich weiß jetzt warum sich das so und so verhält", nein im Sinne von "wenn ich den Owner des Keys umstelle um den Interactive User rauszuwerfen krieg ich eins aufn Deckel".

    Da kläre ich gerade ab wie wir weiter vorgehen wollen ;)

    Gruß

    edit: Der Key zum Share-sharen wird natürlich auch in Betracht gezogen. Kann ich leider nicht testen da mir das die Policy beim Reboot gleich wieder raushaut ;)
    • Bearbeitet buggrabber Freitag, 1. Februar 2013 13:39
    Freitag, 1. Februar 2013 12:58
  • Um das nicht unbeantwortet enden zu lassen:

    Wir werden wieder auf Direktlogin als Admin umgestellt, schränken aber den Ursprung des Logins ein (die Supportmaschinen sind XenDesktops).

    Somit kann ich leider nicht beurteilen, ob die Alternativen funktioniert hätten.

    Trotzdem danke an alle für die Hilfe :)

    Donnerstag, 14. Februar 2013 11:27