Runas, UAC, Fast User Switching: Als Administrator mit Standardrechten arbeiten

    An Windows 8 anmeldenEs gehört zu den goldenen Regeln der Sys­tem­verwaltung, dass Admini­stratoren nicht perma­nent mit vollen Privi­legien arbeiten sollen. Für nor­male Tätigkeiten (Mail, Web, Office) reicht die Anmeldung als Standardnutzer. Die erhöhten Rech­te bleiben Situationen vorbehalten, in denen sie erforderlich sind. Windows bietet dafür mehrere Optionen.

    Unter neueren Versionen von Windows können normale User ihre tägliche Arbeit weitgehend erledigen, ohne dass sie lokale Administratoren sein müssen. Anders als noch unter XP erfordern simple Aktionen wie das Ändern der Zeitzone keine erhöhten Rechte mehr (siehe dazu: Standardbenutzer statt Admini­stratorrechte: Least Privilege in Windows 7).

    Wechsel zwischen Zugriffs-Token per UAC

    Bei Systemverwaltern sieht die Sache naturgemäß anders aus. Sie benötigen per Definition erhöhte Rechte, die jedoch nur wirksam werden sollen, wenn eine administrative Aufgabe dies erfordert. Seit Vista ist die UAC dafür vorgesehen, die Berechtigungen automatisch anzuheben.

    Meldet sich ein User unter einem Administrator­konto an, dann erhält er zwei verschiedene Zugriffs-Token, eines für Standardbenutzer und eines für den Administrator. Beide enthalten die gleichen benutzerspezifischen Informationen, nur dass beim ersten die SIDs und Adminrechte entfernt werden.

    Alle gängigen Aktionen erfolgen danach im Kontext des Standard­benutzers. Sind für eine Aufgabe erhöhte Rechte notwendig, dann fordert die UAC den User automatisch zur Genehmigung auf ("Admin Approval Mode", siehe dazu den umfangreichen Grundlagen­beitrag von Mark Russinovich).

    Die UAC fordert die Zustimmung des Users, wenn erhöhte Rechte benötigt werden.

    Der wesentliche Vorteil dieser Technik besteht darin, dass sich der Benutzer nicht jedes Mal erneut Administrator als anmelden muss. Der Gewinn an zusätzlicher Sicherheit ist somit mit nur geringen Abstrichen beim Komfort verbunden. Nichtsdestotrotz arbeitet der Anwender weiterhin mit einem Administrator­konto, das Ziel verschiedener Angriffe sein kann.

    Auch mit UAC Risiken für Administrator

    Neben Bedrohungen durch Malware oder Hacker spricht auch gegen die Nutzung eines privilegierten Kontos, dass der Administrator die IT-Umgebung aufgrund seiner Zugriffsrechte versehentlich beschädigen kann. Dieses Risiko lässt sich zwar durch die gezielte Delegierung von Rechten reduzieren, so dass etwa nicht alle, die das AD verwalten, automatisch auch Vollzugriff auf die Dateien eines File-Servers erhalten.

    Aufgrund solcher Risiken herrscht in vielen Unternehmen die Vorgabe, dass Systemverwalter sich als Standardbenutzer anmelden müssen. In diesem Fall stellt sich dann die Frage, wie sie ihren administrativen Aufgaben am besten nachkommen, ohne einen unzumutbaren Mehraufwand in Kauf nehmen zu müssen.

    Start von Management-Tools über RunAs

    Eine Möglichkeit, vor allem wenn eine Erhöhung der Rechte nicht häufig ansteht, ist die Verwendung von RunAs. Dieses existiert in einer Version für die Kommandozeile und kann Programme im Kontext eines anderen Benutzers ausführen. Dieses Verfahren hat jedoch mehrere Nachteile:

    • Auch wenn man den Schalter /noprofile verwendet, ändert sich die Umgebung für das Programm, so dass etwa Variablen wie %USERPROFILE% auf das Profil des Administrators zeigen. Bei der Installation von Software kann dies zu unerwünschten Effekten führen.
    • Im Gegensatz zu sudo unter Linux kennt runas keine Frist, während der man ohne erneute Eingabe des Passworts Prozesse mit erhöhten Rechten starten kann. Vielmehr muss man sich für jeden Aufruf eines Programms erneut anmelden (und von /savecred ist abzuraten).
    • Öffnet man stattdessen eine Eingabeauf­forderung mit administrativen Rechten, so dass man zeitlich unbeschränkt alle möglichen Programme von der Kommandozeile ausführen kann, dann muss man die Befehle zum Aufruf der wichtigsten (grafischen) Tools kennen.

    Als Alternative existiert RunAs auch auf der GUI, und zwar im Kontextmenü von Programm­verknüpfungen. Standardmäßig findet man dort nur den Eintrag Als Administrator ausführen.

    Programme kann man über ihr Kontextmenü auch unter dem Namen anderer Benutzer ausführen, wenn man die Shift-Taste drückt.

    Hält man jedoch die Umschalttaste gedrückt, dann erscheint zusätzlich der Befehl Als anderer Benutzer ausführen. Grund­sätzlich gelten auch hier die ersten beiden der oben genannten Nachteile.

    Tools zur Anhebung der Benutzerrechte

    Es ganze Reihe von Tools und Scripts möchte dabei helfen, das wiederholte Eintippen des Passworts zu vermeiden. Einige davon wurden nicht für die neuesten Windows-Versionen aktualisiert, und für die meisten diese kostenlosen Werkzeuge gibt es keinen Support - für eine sicherheits­kritische Software bestimmt keine Empfehlung.

    Beispiele dafür sind RunAsGUI, SuperExec, MakeMeAdmin, das recht ausgefeilte SuRun und diverse mehr oder weniger brauchbare sudo-Implementierungen für Windows. RunasRob ist nur für den privaten Gebrauch kostenlos, so dass es für professionelle Anwender einen Support geben sollte.

    Diese Programme kommen primär dann in Frage, wenn ein normaler Benutzer zur Ausführung einzelner Applikationen gelegentlich erhöhte Rechte benötigen. Für Systemverwalter, die ständig mit Management-Tools hantieren müssen, ist dieses Vorgehen zumeist nicht praktikabel. Ausgewachsene Produkte für das Privilege Management umgehen solche Probleme, aber sie spielen insgesamt in einer anderen Liga.

    Fast User Switching

    Im Dokument Principle of Least Privilege Applied to Windows empfiehlt Microsoft die Verwendung von Fast User Switching (das seit Vista auch verfügbar ist, wenn der PC einer Domäne angehört). Dabei meldet sich der Administrator erst mit seinem normalen Benutzerkonto am PC an und führt nach dem Drücken von Alt + Strg + Entf den Befehl Benutzer wechseln aus. Hier loggt er sich als privilegierter User ein und öffnet so eine zweite parallele Session für ausschließlich administrative Aufgaben.

    Über das Benutzersymbol im Startmenü kann man schnell zur anderen Session wechseln, das Passwort muss man aber immer eingeben.

    Der Vorteil dieses Vorgehens liegt auf der Hand: Eine Anhebung der Rechte im Kontext des normalen Benutzerkontos entfällt und die Admin-Sitzung kann sowohl das lokale Windows als auch Ressourcen im Netzwerk (Server, AD) verwalten.

    Muss man oft zwischen den Sessions wechseln, dann nervt jedoch das ständige Eingeben der Passwörter (am schnellsten schaltet man unter Windows 8.1 und 10 um, indem man auf der Startseite bzw. im Startmenü auf den Namen des angemeldeten Benutzers klickt und aus dem folgenden Menü die alternative Session auswählt).

    VM und RDP-Session

    Der Aufwand für das laufende Eingeben von Passwörtern lässt sich vermeiden, wenn man statt Fast User Switching eine lokale VM unter Hyper-V, VMware Workstation oder VirtualBox ausführt und sich dort als Administrator anmeldet.

    Diese Variante hat aber den Nachteil, dass man dafür eine separate Windows-Lizenz benötigt, es sei denn, man verfügt über eine Software Assurance. Eine VM eignet sich primär für das Management von Servern, Active Directory oder Group Policies, wenn man dort die RSAT installiert. Für die Verwaltung des Windows-Host (oder auch die Installation von Software) muss man dann weiterhin RunAs bemühen.

    Das Gleiche gilt für eine RDP-Session auf einem Windows Server, wobei in diesem Fall aber keine zusätzlichen Lizenzkosten anfallen. Dort dürfen zu administrativen Zwecken bis zu zwei Benutzer gleichzeitig über Remotedesktop angemeldet sein, ohne dass man dafür einen Terminal-Server installieren muss.

    1 Kommentar

    Bild von Sebastian Taraba
    Sebastian Taraba sagt:
    14. Januar 2016 - 12:29

    Eine Anmerkung zur Anmeldung über RunAs (Als anderer Benutzer ausführen)

    Es gibt nur einen Anwendungsfall bei dem ein RunAs zu empfehlen ist und zwar der, dass ich als Admin damit rechne, dass unter meinem Kontext eine Malware läuft die nach der Anmeldung, also während der Anmeldezeit unterwegs ist.

    Für alle anderen Fälle verhält es sich genau wie die UAC. Fatal ist das man denkt man wäre sicher....
    Aus oben bereits beschriebenen Mechanismen erreiche ich mit der UAC dasselbe, was ich auch mit einem RunAs erreiche. UAC arbeitet mit dem angesprochenen Split-Tokenverfahren (Filtered und Fulltoken) und wechselt MIC-Level (Mandatory Integrity Control Level) High, wenn ich dies anfordere > Als anderer Benutzer ausführen.

    Bei beiden Fällen (UAC und RunAs) landet der "Hash im RAM", weil es ein Interactive Logon ist und genau das ist Fatale. Hier ist Pass the Hash möglich, was heutzutage die häufigste Angriffsmethode ist. RunAs bietet also hier genauso viel Schutz wie UAC..

    Des Weiteren muss ich dem Standarduser, welcher vielleicht ein RunAs auf ein Adminkonto machen soll, die Möglichkeit geben seine Privilegien zu erhöhen (standardmäßig wird dies abgelehnt). Ich verringere die Sicherheit also für den gleichen Effekt