TechNet Magazine > Home > Alle Ausgaben > 2008 > June >  Sicherheit: Neue Elevation PowerToys für W...
Sicherheit
Neue Elevation PowerToys für Windows Vista
Michael Murgolo
 
Auf einen Blick:
  • „Run as Administrator“ (Ausführen als Administrator) für Skripterstellungstools von Drittanbietern
  • „Run as Another User“ (Ausführen als anderer Benutzer)
  • „Prompt Here as System“ für CMD und Windows PowerShell
  • Drag & Drop-Elevation-Gadget
Laden Sie den Code für diesen Artikel herunter: Elevation2008_06.exe (197KB)

Willkommen bei einer neuen Ausgabe der Elevation PowerToys für Windows Vista. In der Ausgabe des TechNet Magazins vom Juni 2007 wurde dies bereits eingehend besprochen. Seitdem ist ein Jahr vergangen. Diesmal erfahren Sie, wie die Funktion „Run as Administrator“ für einige
meiner bevorzugten Skripterstellungstools von Drittanbietern erweitert wird und wie ein nützliches Windows® XP-Feature, das in Windows Vista® entfernt wurde, ersetzt werden kann. Zusätzlich finden Sie hier Informationen zu einigen nützlichen Tools, die in den Elevation PowerToys enthalten sind.

„Run as Administrator“ für zusätzliche Skripterstellungstools
Bei einem Thema, das im vorherigen Artikel erörtert wurde (er kann unter technet.microsoft.com/magazine/cc162321.aspx eingesehen werden), ging es um das Aktivieren der Option „Run as Administrator“ bei systemeigenen Windows-Skripterstellungstools. Für diesen Artikel wurden „Run as Administrator“-PowerToys für eine Reihe von Skripterstellungstools von Drittanbietern erstellt:
Der Code ist jeweils im Download für diesen Artikel enthalten. Sie finden Ihn unter technetmagazine.com. Die eigentlichen Dateien heißen „ElevateAutoIt3.inf“, „ElevateAutoHotKey.inf“, „ElevatePerlScript.inf“ und „ElevateKiXtart.inf“. Für AutoIt v3, AutoHotkey und ActivePerl ist die Einrichtung recht einfach. Laden Sie die entsprechende Anwendung herunter, und installieren Sie sie am Standardspeicherort. Nach dem Installieren der für Sie interessanten Anwendungen können Sie das entsprechende „Run as Administrator“-PowerToy für das jeweilige Tool installieren.
Leider stellt KiXtart 2010 kein Installationsprogramm bereit. Um sicherzustellen, dass KiXtart an einem Standardspeicherort installiert wird, damit das PowerToy richtig funktioniert, habe ich eine INF-Datei bereitgestellt, mit der KiXtart 2010 (V 4.60) unter Programme\KiXtart installiert und die .kix-Dateierweiterung registriert wird.
Besuchen Sie www.kixtart.org/?p=downloads, laden Sie KiX2010_460.zip herunter, und entpacken Sie die .zip-Datei in einem Ordner. Kopieren Sie die Install_KiXtart.inf-Datei in denselben Ordner (diese Datei ist im Codedownload zu diesem Artikel enthalten). Dann klicken Sie mit der rechten Maustaste auf Install_KiXtart.inf und wählen „Install“ aus. Anschließend kann das ElevateKiXtart.inf-PowerToy einfach installiert werden.

„Run as Another User“-PowerToy
Die Benutzerkontensteuerung (User Account Control, UAC) wurde erstellt, damit das Betriebssystem gegenüber Malware weniger anfällig ist, indem die Benutzer (selbst Administratoren) die meisten Anwendungen mit Standardbenutzerberechtigungen ausführen. UAC bietet Erhöhungspotenzial für administrative Aufgaben und andere Anwendungsfunktionen. Dieses Erhöhungspotenzial wird mithilfe der Option „Run as Administrator“ bereitgestellt, die durch Klicken mit der rechten Maustaste auf ausführbare Dateien aufgerufen wird. Mit den Elevation PowerToys, die in der Ausgabe vom Juni 2007 vorgestellt wurden, wurde diese Funktion für andere Datei- und Objekttypen erweitert.
Die in Windows Vista integrierte Funktion arbeitet für viele administrative Aufgaben sehr gut. Doch ein wichtiges Szenario wurde bei Windows Vista ausgelassen. In vielen IT-Abteilungen gibt es eine Richtlinie, nach der Netzwerkadministratoren ein Benutzerkonto für ihre alltäglichen Aufgaben (Verwenden von E-Mail, Erstellen von Dokumenten und ähnliches) verwenden und ein anderes Konto nur für die Netzwerkverwaltung (oder lokale Computerverwaltung).
Dadurch soll das Risiko gesenkt werden, dass ein Netzwerkadministrator bei seinen alltäglichen Aufgaben unbeabsichtigt Malware ausführt, wodurch sein gesamtes System oder die Domäne, in der er sich befindet, beeinträchtigt würde. Dies wurde in Windows XP mithilfe der Option „Ausführen als...“ erzielt, die mit der rechten Maustaste aufgerufen wurde. Doch diese Option ist in Windows Vista nicht mehr vorhanden, da sie durch die Option „Ausführen als Administrator“ ersetzt wurde.
Das runas-Befehlszeilentool ist jedoch in Windows Vista immer noch vorhanden. Leider kann es für die häufigsten Doppelkontoaufgaben (das Ausführen von Snap-Ins der Microsoft® Management Console (MMC)) nicht verwendet werden. Ein Beispiel: Angenommen, es wurden einige Kontenverwaltungsaufgaben in Active Directory® an Sie delegiert. Sie führen Ihre alltäglichen Aufgaben als Standardbenutzer aus, und Ihr Netzwerkverwaltungskonto ist auch Mitglied der lokalen Administratorgruppe auf einem Windows Vista-Computer, bei dem UAC aktiviert ist (damit Sie bei Bedarf Netzwerkverwaltungstools installieren können). Sie möchten nun Active Directory User & Computer (ADU&C) mit Ihrem Active Directory-Administratorkonto starten. Sie versuchen es wie folgt mit dem runas-Befehl:
runas /user:mydomain\admin
"mmc.exe %windir%\system32\dsa.msc"
Leider wird ADU&C dadurch nicht gestartet. Stattdessen erhalten Sie die runas-Fehlermeldung „Der angeforderte Vorgang erfordert erhöhte Rechte.“ In diesem Fall geschieht Folgendes: Die ausführbare MMC-Datei ist so gekennzeichnet, dass sie auf der highestAvailable-Berechtigungsstufe ausgeführt wird. Da „Administrator“ die highestAvailable-Ebene für Ihr Netzwerkverwaltungskonto ist, wäre für das Starten von ADU&C auf diese Weise eine Erhöhung erforderlich. Da „runas“ keine Aufforderung zur Erhöhung gibt, kommt es zu diesem Fehler.
Windows Vista erschwert dieses Szenario also, indem kein Kontextmenüelement für „Ausführen als...“ und keine integrierten Möglichkeiten zum Ausführen eines Prozesses als anderer Benutzer bereitgestellt werden, für den Erhöhung erforderlich ist.
Dieser Artikel wäre sehr frustrierend, wenn es dafür keine Lösung gäbe, doch glücklicherweise stellt eins meiner ursprünglichen Elevation PowerToys die Lösung für das zweite Problem bereit, und auch für das erste wurde eine Lösung gefunden. (Leider habe nicht ich die Lösung für das Erhöhungsproblem gefunden, sondern Gov Maharaj im Windows AppCompat-Team.)
Wie sich herausstellt, kann das Elevate Command PowerToy mit dem runas-Befehl verwendet werden. Da der vorherige Befehl bei der Aufforderung für erweiterten Zugriff versagt hat, wird die Aufforderung nun folgendermaßen ausgelöst:
runas /user:mydomain\admin
"elevate mmc.exe%windir%\system32\dsa.msc"
Dies führt dazu, dass „runas“ elevate.cmd als anderer Benutzer startet (technisch gesehen handelt es sich bei dem gestarteten Prozess um cmd.exe), und der elevate-Befehl sorgt dafür, dass mmc.exe mit einer Aufforderung für erweiterten Zugriff gestartet wird.
Schließlich habe ich diesen Trick mit den Dateizuordnungen für .exe- und .msc-Dateien kombiniert und ihn mit einer HTML-Anwendungsoberfläche versehen, um ein PowerToy zu erstellen, das die Option „Run as Another User“ erstellt, die über das Kontextmenü zugänglich ist. Wenn Sie „Run as Another User“ auswählen, erhalten Sie eine HTML-Anwendung wie die in Abbildung 1 dargestellte.
Abbildung 1 Tool für „Run as Another User“ (Zum Vergrößern auf das Bild klicken)
Hier geben Sie einfach nur den Benutzernamen und die Domäne ein. Für ein Konto auf dem lokalen Computer aktivieren Sie das Kontokontrollkästchen „Use Local Account“ (Lokales Konto verwenden). Dann kann die Anwendung durch Klicken auf die Schaltfläche „Ausführen“ als Standardbenutzer ausgeführt werden. Alternativ klicken Sie auf die Schaltfläche „Run as Admin“, um die Anwendung mit erhöhten Berechtigungen zu starten. Nach dem Klicken auf eine der beiden Schaltflächen wird runas.exe ausgeführt und eine Aufforderung zur Eingabe eines Kennworts oder einer Smartcard-PIN angezeigt.
Da dieses PowerToy das Elevate Command PowerToy verwendet, muss dieses zuerst installiert werden. Dann klicken Sie mit der rechten Maustaste auf die RunAs.inf-Datei, wählen „Install“ aus und genehmigen die Erhöhung. Zum Deinstallieren des Tools verwenden Sie das Dienstprogramm für Programme und Features in der Systemsteuerung.
Sie werden feststellen, dass einige Verknüpfungen mit .msc-Dateien in der Verwaltung (beispielsweise die Computerverwaltung) mit diesem PowerToy funktionieren. Beachten Sie jedoch Folgendes: Wenn die Windows Server® 2003-Verwaltungstools mithilfe von adminpak.msi installiert werden, sind die erstellten Verknüpfungen keine Standardverknüpfungen mit den .msc-Dateien. Vielmehr handelt es sich um Windows Installer-Verknüpfungen, und daher zeigt Windows-Explorer die Option „Run as Another User“ für diese Verknüpfungen nicht an.
Für diese Verknüpfungen müssen Sie entweder die eigentlichen .msc-Dateien suchen und mit der rechten Maustaste auf sie klicken oder neue Verknüpfungen zu den .msc-Dateien erstellen. Außerdem funktioniert „runas“ nicht mit Internet Explorer® aufgrund der Art und Weise, wie Internet Explorer für den geschützten Modus in Windows Vista neu entworfen wurde (zusätzliche Informationen dazu finden Sie unter support.microsoft.com/?id=922980).
Hinweis: Seit dem Abschluss meiner Arbeiten an diesen PowerToys und der Veröffentlichung dieses Artikels hat Windows Sysinternals ein neues Tool veröffentlicht, dessen Funktion meinem „Run as Another User“-PowerToy sehr ähnelt. Es heißt ShellRunas. Sie finden es auf der Windows Sysinternals-Website: technet.microsoft.com/sysinternals/cc300361.
Da die Mitarbeiter bei Sysinternals ihren Lebensunterhalt mit dem Schreiben von Code verdienen, bevorzugen Sie möglicherweise ihr Tool. Ich habe entschieden, mein Tool in diesem Artikel als Beispiel dafür zu belassen, wie diese Aufgabe im Besonderen und Shellerweiterungen im Allgemeinen mithilfe von HTML-Anwendungen mit Skriptcode durchgeführt werden können.

CMD- und PowerShell-„Prompt Here as System“
Hin und wieder ist es erforderlich, Programme im Kontext „Lokales System“ auszuführen. So verwenden viele Softwareverteilungstools, z. B. System Center Configuration Manager (SCCM), einen Client-Agent, der zum Durchführen seiner Aufgaben als „Lokales System“ ausgeführt wird.
Um das Verhalten eines Softwareinstallationsprogramms zu testen, das als „Lokales System“ ausgeführt wird, bevor versucht wird, eine Verteilung mit einem Produkt wie SCCM durchzuführen, kann es hilfreich sein, das Installationsprogramm mithilfe einer Eingabeaufforderung zu starten, die als „Lokales System“ ausgeführt wird. Daher habe ich die CMD- und PowerShell-„Prompt Here as System“-PowerToys erstellt.
In Windows XP konnte eine solche Funktion mit einem Befehlsshellskript durchgeführt werden:
@echo off
sc create CmdAsSystem type= own type= interact
binPath= "cmd /c start cmd /k (cd c:\ ^& color ec ^& 
title ***** SYSTEM *****)"
net start CmdAsSystem
sc delete CmdAsSystem
Wenn Sie jedoch versuchen, diese Funktion in Windows Vista von einer erhöhten Eingabeaufforderung aus auszuführen, erhalten Sie folgende Fehlermeldung, und die Eingabeaufforderung, die als „System“ ausgeführt wird, wird nicht angezeigt:
WARNUNG: Der Dienst "CmdAsSystem" ist als interaktiver Dienst konfiguriert, dessen Unterstützung abgelehnt wurde. Die einwandfreie Funktion des Dienstes ist nicht gewährleistet.
Das Problem besteht darin, dass dieses Skript versucht, einen interaktiven Dienst zu erstellen und zu starten. Interaktive Dienste funktionieren aufgrund der Sitzung 0-Isolierung in Windows Vista nicht richtig. (Eine Erläuterung der Sitzung 0-Isolierung finden Sie im Whitepaper „Dienste in Windows Vista “, das unter microsoft.com/whdc/system/vista/Vista_Services.mspx verfügbar ist.)
Zur Problemumgehung habe ich das von Sysinternals entwickelte Psexec-Tool verwendet (siehe technet.microsoft.com/sysinternals/bb897553.aspx). Mithilfe dieses Tools können Prozesse im Kontext „System“ gestartet werden. Leider enthalten die meisten Sysinternals-Tools kein Installationsprogramm. Daher habe ich eine INF-Datei (verfügbar im Codedownload) zum Installieren der gesamten Sysinternals-Suite (einschließlich Psexec) in Programme\Sysinternals Suite bereitgestellt. Als Zugabe erstellt diese INF-Datei Startmenüverknüpfungen für die grafischen Tools der Suite.
Zum Installieren der Suite laden Sie zuerst SysinternalsSuite.zip von technet.microsoft.com/sysinternals/bb842062.aspx herunter und entpacken die .zip-Datei in einem Ordner. Kopieren Sie die INF-Datei (Install_SysinternalsSuite.inf) in diesen Ordner, klicken Sie mit der rechten Maustaste auf Install_SysinternalsSuite. inf, und wählen Sie „Install“ aus. Da diese neuen PowerToys das Elevate Command PowerToy verwenden, installieren Sie es als Nächstes. Anschließend können Sie CmdHereAsSystem.inf und PowerShellHereAsSystem.inf installieren. Nach der Installation dieser PowerToys stehen Ihnen die Optionen „CMD Prompt Here as System“ und „PowerShell Prompt Here as System“ zur Verfügung, die über das Kontextmenü für Ordner und Laufwerke in Windows-Explorer zugänglich sind, wie in Abbildung 2 dargestellt.
Abbildung 2 Die Optionen „CMD Prompt Here as System“ und „PowerShell Prompt Here as System“ 
Abbildung 3 zeigt eine CMD-Eingabeaufforderung, die als System ausgeführt wird. Ich habe die hellen Farben als Erinnerung daran ausgewählt, dass diese Eingabeaufforderung als „System“ ausgeführt wird und unerwartete (und gefährliche) Folgen im System nach sich ziehen kann, wenn die falschen Befehle eingegeben werden.
Abbildung 3 „CMD Prompt as System“ muss verantwortungsbewusst verwendet werden. 
Schließlich fügen diese PowerToys dem System Befehle hinzu, sodass diese Eingabeaufforderungen im Dialogfeld „Ausführen“ oder als CMD-Eingabeaufforderung ausgeführt werden können. So startet beispielsweise das Ausführen des folgenden Befehls im Feld „Ausführen“ eine CMD-Eingabeaufforderung als „System“ im Windows-Ordner:
cmdassystem "c:\windows"
Der entsprechende Befehl für Windows PowerShellTM ist „psassystem“. Beachten Sie, dass auch die CMD- und PowerShell-„Prompt Here as Administrator“-PowerToys geändert wurden, um ähnliche Befehle zu installieren („cmdasadmin“ bzw. „psasadmin“).

Elevation-Gadget
Für die meisten der PowerToys ist das Klicken mit der rechten Maustaste erforderlich. Doch als Zugabe zu dieser Aktualisierung finden Sie hier etwas, das mehr Spaß macht. Es handelt sich dabei um ein Gadget in der Windows-Sidebar, das ich als Elevation-Gadget bezeichne (dargestellt in Abbildung 4). Es wird mit Drag & Drop ausgeführt. Ziehen Sie einfach eine ausführbare Datei oder ein Skript aus dem Windows-Explorer, bei dem eine runas-Aktion definiert ist, und es wird als erhöht gestartet.
Abbildung 4 Das Drag & Drop-Elevation-Gadget 
Wenn Sie die vorherigen Elevation PowerToys installiert haben, funktioniert dies für Windows Script Host-Skripts, Windows PowerShell-Skripts, HTML-Anwendungen und Windows Installer-Pakete und -Patches (sowie für ausführbare Dateien und Befehlsshellskripts, für die standardmäßig eine runas-Aktion in Windows Vista definiert ist). Zudem können Sie gleichzeitig mehr als ein Element auf einmal ziehen. (Versuchen Sie einmal, einen Ordner auf das Gadget zu ziehen, um zu sehen, was geschieht.)
Zum Installieren des Gadget doppelklicken Sie auf Elevation.gadget (verfügbar im Codedownload). Wenn Sie sich den Code für das Gadget ansehen möchten, fügen Sie dem Dateinamen einfach die .cab-Erweiterung hinzu. Dann können Sie den Inhalt der Cab-Datei extrahieren.

Zusammenfassung
Der Download für diesen Artikel enthält sowohl die neuen PowerToys als auch die aus dem ursprünglichen Artikel. An den alten wurden kleine Änderungen vorgenommen. So installierten beispielsweise die ursprünglichen Versionen von Windows PowerShell-„Prompt Here as Administrator“ und „Elevate WSH Script“ beide ihre eigenen Kopien von elevate.cmd und elevate.vbs. Da diese Dateien auch für mehrere neue PowerToys erforderlich sind, wurden diese Tools so geändert, dass für sie das Elevate Command PowerToy installiert werden muss (beide verwenden dann diese Kopie). Um festzustellen, ob für ein PowerToy die Installation von Elevate Command PowerToy erforderlich ist, prüfen Sie den Header in der INF-Datei.
An einigen anderen ursprünglichen PowerToys wurden ebenfalls geringfügige, nicht funktionale Änderungen vorgenommen. Deinstallieren Sie immer die alte Version eines PowerToy, bevor Sie die aktuelle Version installieren. Da diese Sammlung nun auf 17 Tools angewachsen ist, sind Befehlsshellskripts zum Installieren und Deinstallieren der gesamten Sammlung beigefügt (InstallAllPowerToys.cmd bzw. UninstallAllPowerToys.cmd). Sie können angepasst werden, sodass nur die Tools, die Sie brauchen, installiert und deinstalliert werden.
Bedenken Sie, dass durch InstallAllPowerToys.cmd nicht standardmäßig die „Run as Administrator“-PowerToys für Skripterstellungstools von Drittanbietern installiert werden. Sie können dieses Skript so ändern, dass nur die PowerToys installiert werden, für die Sie die Software installiert haben. Wenn Sie eins der beiden Skripts ausführen, wird es als erhöht neu gestartet. Mit UninstallAllPowerToys.cmd werden alle alten Versionen dieser Tools ebenfalls entfernt.
Wie bei allen PowerToys gilt: Diese Tools werden nicht unterstützt, und ihre Verwendung erfolgt auf eigenes Risiko. Es handelt sich nicht um offizielle Microsoft-Produkte, sondern um meine eigenen persönlichen Entwürfe. Sie wurden nur von mir und einigen anderen Freiwilligen unter 32-Bit-Windows Vista mit US-Englisch als Standardsprache getestet. Es ist möglich, dass einige oder alle dieser PowerToys mit zukünftigen Windows-Updates, Service Packs oder Betriebssystemversionen nicht funktionieren.

Michael Murgolo ist leitender Infrastrukturberater für Microsoft Consulting Services. Er ist auf die Bereiche Betriebssysteme, Bereitstellung, Netzwerkdienste, Active Directory, Systemverwaltung, Automatisierung und Patchverwaltung spezialisiert. Zu seinen Fachgebieten zählen die Desktopbereitstellung und die Migration.
© 2008 Microsoft Corporation und CMP Media, LLC. Alle Rechte vorbehalten. Die nicht genehmigte teilweise oder vollständige Vervielfältigung ist nicht zulässig.
Page view tracker