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:
- Typ geändert Alex Pitulice Freitag, 1. Februar 2013 12:53 Warten auf Testen
Alle Antworten
-
Hallo Oliver,
bist Du hier weitergekommen?
Danke und Gruss,
Alex
