11
Administrative Aufgaben im User-Kontext innerhalb von Batch-Dateien
Bedingungen: Windows-Netzwerk, Active Directory, Clients von Win XP bis 7, Alle Benutzer haben normale USER/BENUTZER-Privilegien.
Um eine spezielle Software per BAT-Datei zu starten, müssen im Bedarfsfall (Abhängigkeiten werden vorher abgeprüft) einige Sachen nachinstalliert bzw. Einträge im Registry-Zweig HKLM verändert/hinzugefügt werden. Hierfür werden Admin-Rechte benötigt.
Wie stellt man das jetzt am besten an, ohne das Passwort eines Administrator-Kontos im Klartext irgendwo zu hinterlegen.
So etwas muss mit Windows-Boardmitteln möglich sein. Z.B. beim SAP-Installationsserver geht das auch, dass am Client im Benutzer-Kontext der SAP-GUI installiert/aktualisiert wird, wo definitiv Admin-Privilegien erforderlich sind. Dort hat man einfach einen Benutzer im AD angelegt, der diese Aufgabe dann übernimmt.
Die Sache mit der GPO-Softwareverteilung oder dem Taskplaner zu machen, fällt aus, da -wie gesagt- die Aktionen interaktiv und nur im Bedarfsfall gemacht werden sollen. RunAs scheidet meiner Meinung nach auch aus, da dort ein Kennwort hinterlegt sein muss oder abgefragt werden muss.
Das ganze muss vor allem unter Windows 7 sauber funktionieren. Kann man die UAC bei diesen Aktionen temporär ausschalten? Wenn nicht, ist auch OK. Die Benutzer gewöhnen sich dran. Ganz abschalten möchte ich UAC auch nicht.
Sicherlich ein alter Hut, aber ich finde nix Brauchbares im Netz.
Wer kann mir auf die Sprünge helfen?
Shiva99
Um eine spezielle Software per BAT-Datei zu starten, müssen im Bedarfsfall (Abhängigkeiten werden vorher abgeprüft) einige Sachen nachinstalliert bzw. Einträge im Registry-Zweig HKLM verändert/hinzugefügt werden. Hierfür werden Admin-Rechte benötigt.
Wie stellt man das jetzt am besten an, ohne das Passwort eines Administrator-Kontos im Klartext irgendwo zu hinterlegen.
So etwas muss mit Windows-Boardmitteln möglich sein. Z.B. beim SAP-Installationsserver geht das auch, dass am Client im Benutzer-Kontext der SAP-GUI installiert/aktualisiert wird, wo definitiv Admin-Privilegien erforderlich sind. Dort hat man einfach einen Benutzer im AD angelegt, der diese Aufgabe dann übernimmt.
Die Sache mit der GPO-Softwareverteilung oder dem Taskplaner zu machen, fällt aus, da -wie gesagt- die Aktionen interaktiv und nur im Bedarfsfall gemacht werden sollen. RunAs scheidet meiner Meinung nach auch aus, da dort ein Kennwort hinterlegt sein muss oder abgefragt werden muss.
Das ganze muss vor allem unter Windows 7 sauber funktionieren. Kann man die UAC bei diesen Aktionen temporär ausschalten? Wenn nicht, ist auch OK. Die Benutzer gewöhnen sich dran. Ganz abschalten möchte ich UAC auch nicht.
Sicherlich ein alter Hut, aber ich finde nix Brauchbares im Netz.
Wer kann mir auf die Sprünge helfen?
Shiva99
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 168055
Url: https://administrator.de/contentid/168055
Ausgedruckt am: 25.11.2024 um 11:11 Uhr
11 Kommentare
Neuester Kommentar
Moin Moin
Also für ...
Gruß L.
Also für ...
die Aktionen interaktiv und nur im Bedarfsfall gemacht werden sollen.
Brauchst du den Benutzerkontext doch nicht. Da führst du deine Skripte per PSExec oder Powershell remote aus, oder Du machst gleich eine RDP session auf. Natürlich als Administrator.Gruß L.
Wie gesagt, es soll innerhalb eines Batch-Files laufen. Vielleicht habe ich mich nicht ganz richtig ausgedrückt.
Beispiel 1:
1. <Benutzer hat Menüpunkt 1 gewählt>
2. Prüfe auf VBA-Installation
3. Wenn nicht vorhanden, installiere VBA als Admin
4. Prüfe auf Registry-Eintrag
5. Wenn nicht vorhanden, setze Registry-Eintrag als Admin
6. Starte Haupt-Anwendung
Beispiel 2:
1. <Benutzer hat Menüpunkt 3 gewählt>
2. Prüfe auf DotNet3.5-Service-Pack
3. Wenn nicht vorhanden, installiere DotNet3.5SP als Admin
4. Prüfe auf Registry-Eintrag
5. Wenn vorhanden, lösche Registry-Eintrag als Admin
6. Starte Haupt-Anwendung
usw.
Ich will nichts remote (per psexec, PS oder RDP) machen. Es soll automatisiert am Client ablaufen.
Gruß, shiva99
Beispiel 1:
1. <Benutzer hat Menüpunkt 1 gewählt>
2. Prüfe auf VBA-Installation
3. Wenn nicht vorhanden, installiere VBA als Admin
4. Prüfe auf Registry-Eintrag
5. Wenn nicht vorhanden, setze Registry-Eintrag als Admin
6. Starte Haupt-Anwendung
Beispiel 2:
1. <Benutzer hat Menüpunkt 3 gewählt>
2. Prüfe auf DotNet3.5-Service-Pack
3. Wenn nicht vorhanden, installiere DotNet3.5SP als Admin
4. Prüfe auf Registry-Eintrag
5. Wenn vorhanden, lösche Registry-Eintrag als Admin
6. Starte Haupt-Anwendung
usw.
Ich will nichts remote (per psexec, PS oder RDP) machen. Es soll automatisiert am Client ablaufen.
Gruß, shiva99
Hallo Shiva99,
wenn ich dich richtig verstehe, möchtest du also (kurz gefasst) innerhalb einer Batch einige Aktionen als Admin ausführen.
Mir würde aber keine Methode einfallen, es zu machen, ohne irgendwo Benutzer und Passwort zu hinterlegen.
Du könntest die Daten natürlich verschleiern, so dass es auf den ersten Blick nicht ersichtlich ist, oder die Rechte dieses Admin-Users so einschränken, dass die User mit den Daten nichts anfangen können.
Grundsätzlich kannst du die User-Daten überall hinterlegen, auch in Textdateien, einer Datenbank, oder was weiss ich...
Oder: Dein Batch merkt sich, dass es die benannten Sachen installieren muss, hinterlegt diese Info und dann wird remote (wenn du dich überreden lässt), am Besten automatisiert oder however ein Script gestartet, was die benötigten Aktionen ausführt...
Möglich ist es auf jeden Fall und Remote wäre die (meiner Meinung nach) beste Methode...
Gruß
Dominique
wenn ich dich richtig verstehe, möchtest du also (kurz gefasst) innerhalb einer Batch einige Aktionen als Admin ausführen.
Mir würde aber keine Methode einfallen, es zu machen, ohne irgendwo Benutzer und Passwort zu hinterlegen.
Du könntest die Daten natürlich verschleiern, so dass es auf den ersten Blick nicht ersichtlich ist, oder die Rechte dieses Admin-Users so einschränken, dass die User mit den Daten nichts anfangen können.
Grundsätzlich kannst du die User-Daten überall hinterlegen, auch in Textdateien, einer Datenbank, oder was weiss ich...
Oder: Dein Batch merkt sich, dass es die benannten Sachen installieren muss, hinterlegt diese Info und dann wird remote (wenn du dich überreden lässt), am Besten automatisiert oder however ein Script gestartet, was die benötigten Aktionen ausführt...
Möglich ist es auf jeden Fall und Remote wäre die (meiner Meinung nach) beste Methode...
Gruß
Dominique
Hallo!
Die Lösung steht hier; http://openbook.galileocomputing.de/microsoft_netzwerk/microsoft_netzwe ...
Man benutzt psexec um innerhalb eines Skript ein anderes Skript mit Admin-Rechten zu starten. Wie man das Passwort für dieses Konto verschlüsseln kann, ist dort ebenfalls erklärt.
Habe ich seit Jahren im Einsatz, ist relativ einfach und funktioniert super.
Gruß
Tobias
Die Lösung steht hier; http://openbook.galileocomputing.de/microsoft_netzwerk/microsoft_netzwe ...
Man benutzt psexec um innerhalb eines Skript ein anderes Skript mit Admin-Rechten zu starten. Wie man das Passwort für dieses Konto verschlüsseln kann, ist dort ebenfalls erklärt.
Habe ich seit Jahren im Einsatz, ist relativ einfach und funktioniert super.
Gruß
Tobias
Wie man das Passwort für dieses Konto verschlüsseln kann, ist dort ebenfalls erklärt.
Und wenn er die exe ausführt wird die Bat in ein temp. Verzeichnis für jeden lesbar extrahiert (?)
Das macht es doch nicht sicherer, oder?
@dominique01520
Soweit ich weiß, ist das Passwort zu keiner Zeit lesbar.
Soweit ich weiß, ist das Passwort zu keiner Zeit lesbar.
Bat2Exe Konverter müssen doch wohl gezwungenermaßen das BAT-File irgendwo ablegen, um dieses dann auszuführen.
In dem Moment, in dem das Batch ausgeführt wird, ist es für Jedermann lesbar (Rechte Maustaste ->Bearbeiten) Wo es sich genau versteckt, weiss ich nicht. Normalerweise irgendwo im TEMP-Ordner...
In dem Moment, in dem das Batch ausgeführt wird, ist es für Jedermann lesbar (Rechte Maustaste ->Bearbeiten) Wo es sich genau versteckt, weiss ich nicht. Normalerweise irgendwo im TEMP-Ordner...
Die Batch-Datei darf ja lesbar sein, das Passwort steht verschlüsselt nur in der EXE -
und die wird nicht in eine Batch-Datei umgewandelt.
Kennst du das Tool oder vermutest du das nur?
und die wird nicht in eine Batch-Datei umgewandelt.
Kennst du das Tool oder vermutest du das nur?
[OT]
Das Problem ist einfach, ich habe in zwei Personen gedacht.
Die eine Person las das Verschlüsseln, die andere das compilieren.
Die, die das compilieren und Kompirimieren las, ging davon aus, das PW ist in der ursprünglichen Bat als PT hinterlegt...
Und wollte dann einen halbprduktiven Beitrag leisten, der diese Erkenntnis preisgibt...
Das Problem ist einfach, ich habe in zwei Personen gedacht.
Die eine Person las das Verschlüsseln, die andere das compilieren.
Die, die das compilieren und Kompirimieren las, ging davon aus, das PW ist in der ursprünglichen Bat als PT hinterlegt...
Und wollte dann einen halbprduktiven Beitrag leisten, der diese Erkenntnis preisgibt...
Danke für die Lösungsansätze.
Der "Bat To Exe Converter" sieht sehr vielversprechend aus.
Nach parallelen Recherchen habe ich auch noch das Tool "runasspc.exe" gefunden. In Verbindung mit "elevate.exe" scheint es auch eine saubere Lösung für UAC-geplagte zu sein. Werde mich morgen mal damit beschäftigen.
Danke erst mal an alle hier. Melde mich zurück, wenn ich neue Erkenntnisse habe.
Shiva99
Der "Bat To Exe Converter" sieht sehr vielversprechend aus.
Nach parallelen Recherchen habe ich auch noch das Tool "runasspc.exe" gefunden. In Verbindung mit "elevate.exe" scheint es auch eine saubere Lösung für UAC-geplagte zu sein. Werde mich morgen mal damit beschäftigen.
Danke erst mal an alle hier. Melde mich zurück, wenn ich neue Erkenntnisse habe.
Shiva99
Hallo Tobias,
allen diesen Batch-Nach-Exe-Konvertern ist gemein, dass sie nicht etwa den Code des Batchscripts compilieren, sondern als Daten in die erzeugte EXE einbinden. Die EXE besteht weiterhin aus einem kurzen Programm, die den Code des Batchscripts in eine temporäre Datei schreibt und dann CMD mit der Anweisung startet, die erzeugte Batchdatei auszuführen.
Die im von Dir geposteten Link verwendete Methode, die erzeugte EXE mit UPX zu komprimieren, verhindert nur, dass die dem Anwender übergebene EXE in einen Hexeditor geladen und somit Benutzer und Passwort ausgelesen werden kann.
Wenn diese EXE gestartet wird, wird der Unpacker von UPX ausgeführt, der die in der Datei enthaltene EXE im Speicher auspackt und startet. Jetzt läuft also die ursprüngliche vom Batch-Nach-EXE-Konverter erstellte EXE. Diese muss den enthaltenen Code (das Batchscript mit dem
=> Zumindest während der Ausführung des Batchfiles existiert irgendwo auf der Festplatte, höchstwahrscheinlich im TEMP-Verzeichnis, das Batchfile mit dem
Die einzige Möglichkeit das zu verhindern bestünde darin, dass die vom Batch-Nach-EXE-Konverter erzeugte EXE das Script nicht in eine Datei schreibt, sondern das ganze Script Zeile für Zeile durch den Operator
=> Es sieht so aus, als ob Du das, was Du da empfiehlst, selbst nicht verstanden hast.
Gruß
Friemler
allen diesen Batch-Nach-Exe-Konvertern ist gemein, dass sie nicht etwa den Code des Batchscripts compilieren, sondern als Daten in die erzeugte EXE einbinden. Die EXE besteht weiterhin aus einem kurzen Programm, die den Code des Batchscripts in eine temporäre Datei schreibt und dann CMD mit der Anweisung startet, die erzeugte Batchdatei auszuführen.
Die im von Dir geposteten Link verwendete Methode, die erzeugte EXE mit UPX zu komprimieren, verhindert nur, dass die dem Anwender übergebene EXE in einen Hexeditor geladen und somit Benutzer und Passwort ausgelesen werden kann.
Wenn diese EXE gestartet wird, wird der Unpacker von UPX ausgeführt, der die in der Datei enthaltene EXE im Speicher auspackt und startet. Jetzt läuft also die ursprüngliche vom Batch-Nach-EXE-Konverter erstellte EXE. Diese muss den enthaltenen Code (das Batchscript mit dem
PSExec-Aufruf) in eine Datei schreiben, die dann CMD als Parameter übergeben und damit ausgeführt wird.=> Zumindest während der Ausführung des Batchfiles existiert irgendwo auf der Festplatte, höchstwahrscheinlich im TEMP-Verzeichnis, das Batchfile mit dem
PSExec-Aufruf inkl. Benutzer und Passwort im Klartext. Die einzige Möglichkeit das zu verhindern bestünde darin, dass die vom Batch-Nach-EXE-Konverter erzeugte EXE das Script nicht in eine Datei schreibt, sondern das ganze Script Zeile für Zeile durch den Operator
& verkettet und mit der Option /c als Parameter an CMD übergibt. Diese Methode würde schon bei einem einfachen IF-Befehl, der durch die Verwendung von Klammern über mehrere Zeilen verteilt ist, fehlschlagen. Ich halte es deshalb für unwahrscheinlich, dass der Programmierer eines Batch-Nach-EXE-Konverters versuchen würde, diesen Weg zu gehen.=> Es sieht so aus, als ob Du das, was Du da empfiehlst, selbst nicht verstanden hast.
Gruß
Friemler
