Programm als anderer Benutzer ausführen: RunAs in der Windows-Kommandozeile

Zwei Konten, ein Desktop. Das klingt nach einem Sonderfall und ist Alltag: eine Administratorin, die als Standardbenutzerin angemeldet ist, ein Support-Mitarbeiter am Rechner einer anderen Person, eine Entwicklerin, die prüft, was ein eingeschränktes Konto wirklich sieht. Wer ein Programm unter einem anderen Konto starten will, hat dafür einen eingebauten Weg, und dieser Weg, ein Programm als anderer Benutzer ausführen zu lassen, hat drei Schreibweisen mit sehr unterschiedlichen Folgen.

Der Befehl runas auf der Kommandozeile und was er nicht tut

runas gehört seit Windows 2000 zum Lieferumfang und ist der kürzeste Weg von einer Kommandozeile zu einer zweiten Identität. Er fordert beim Dienst für sekundäre Anmeldungen ein Token an, lädt gegebenenfalls das Profil dieses Kontos und startet den Prozess.

C:\> runas /user:BISTRO\svc_report "mmc.exe compmgmt.msc"
Geben Sie das Kennwort für BISTRO\svc_report ein:

C:\> runas /user:[email protected] /netonly "explorer.exe \\FS01\berichte"

Zwei Schalter sind es wert, gemerkt zu werden, weil sie ändern, wofür das Token gilt. /netonly behält die lokale Identität und legt die anderen Anmeldedaten nur Remote-Rechnern vor. Passend, wenn das Konto in einer anderen Domäne liegt und lokal kein Profil hat. /savecred speichert das Kennwort, damit der nächste Start nicht fragt: bequem, und eine echte Sicherheitsentscheidung statt einer Bequemlichkeitsfrage.

Was runas nicht tut, ist erhöhen. Er ändert, wer der Prozess ist, nicht, was der Prozess darf; ein so gestartetes Standardkonto ergibt einen Standardkonto-Prozess. Er funktioniert außerdem nicht, wenn dem Zielkonto die interaktive Anmeldung auf diesem Rechner verweigert ist, und er startet nichts auf einem anderen Computer.

Drei Wege, ein Vorgang

Kontextmenü

Umschalt + Rechtsklick → Als anderer Benutzer ausführen. Ein Programm, eine Abfrage, nicht skriptbar.

Kommandozeile

runas /user:DOMÄNE\name "programm". Skriptbar, Rückgabewerte verfügbar.

PowerShell

Start-Process -Credential (Get-Credential) -FilePath …. Anmeldeobjekt im Skript wiederverwendbar.

Dienst dahinter

Sekundäre Anmeldung (seclogon). Ist er deaktiviert, scheitern alle drei gleich.

Nicht so

jedes Werkzeug, das SeTcbPrivilege für gewöhnliche Benutzerkonten verlangt.

Warum die Privilegienfrage entscheidet, welches Werkzeug taugt

Die interessante Einschränkung ist nicht, wie man an ein Token kommt, sondern wie man an eines kommt, ohne ein Privileg zu vergeben, das den Zweck zerstört. Mehrere Werkzeuge der Windows-NT-Zeit baten Administratoren, den nutzenden Konten „Als Teil des Betriebssystems handeln" zu gewähren. Dieses Privileg erlaubt, ein beliebiges Token zusammenzusetzen. Wer es hält, kann sich in die Administratorengruppe eintragen. Ein Werkzeug, das es braucht, hat aus einem eingeschränkten Konto ein unbeschränktes gemacht, damit es ein Programm als anderer Benutzer ausführen kann.

Die Werkzeuge, die das gut lösten, gingen stattdessen über den dokumentierten Anmeldeweg, und dann braucht kein Konto irgendein Sonderprivileg. Diese Unterscheidung ist das Nützlichste, was man an jedem Werkzeug dieser Art prüfen kann, auch an aktuellen: steht in der Einrichtungsanleitung eine Privilegienvergabe, lohnt genaues Lesen, bevor man ihr folgt.

Mehrere Sitzungen auf einem Rechner, damals und heute

Ein einzelnes Programm als anderer Benutzer ausführen zu lassen ist die kleine Fassung des Problems. Wer nur gelegentlich ein Programm unter einem anderen Konto starten muss, ist damit fertig. Die große ist ein ganzer Desktop (Shell, Taskleiste, Profil) als jemand anders, während die eigene Sitzung stehen bleibt. Windows XP brachte dafür die schnelle Benutzerumschaltung; Windows NT und Windows 2000 hatten nichts Vergleichbares, weshalb es eine kleine Klasse von Werkzeugen gab, die es nachrüsteten.

NetExec, ab 1997 für Windows NT veröffentlicht und bis 2002 weiterentwickelt, war eines der frühesten. Sein Desktop-Manager erzeugte zusätzliche Anmeldesitzungen, jede auf eigenem Desktop, mit einem Symbol im Infobereich zum Umschalten; Sitzungen ließen sich mit Kennwort schützen und beim Abmelden der Hauptsitzung automatisch schließen. Daneben standen eine Kommandozeilen-Schnittstelle und ein Generator, der kleine ausführbare Dateien mit verschlüsselten Anmeldedaten und festem Ziel erzeugte: auf Wunsch mit einer Prüfsumme über dieses Ziel, sodass der Starter die Ausführung verweigerte, wenn das Ziel ausgetauscht worden war.

Diese Fähigkeiten lesen sich als Inventar dessen, was der Plattform damals fehlte: sitzungsbezogene Laufwerksbuchstaben, Hintergrundbild und Taskleistengeometrie je Desktop, Verbinden des Basisverzeichnisses beim Sitzungsstart, Ausführen des Anmeldeskripts und eine Kompatibilitätsschicht für Anwendungen, die eine zweite Instanz verweigerten. Fast alles davon ist heute eingebaut oder unnötig. Geblieben ist die Überlegung: eine zweite Sitzung ist eine echte Anmeldung, sie kostet ein Profil und ein Token, und wer etwas anderes behauptet, fälscht eines von beiden.

Zum Namen

Der Name NetExec ist inzwischen weit bekannter für ein völlig anderes, aktuelles Open-Source-Werkzeug zur Netzwerkausführung im Sicherheitstest. Den Nachfolger von CrackMapExec. Die beiden haben nichts gemeinsam außer dem Namen: Gegenstand dieser Seite ist ein Mehrsitzungs- und RunAs-Werkzeug für Windows NT aus den späten 1990ern. Wer das Netzwerkwerkzeug sucht, ist hier falsch.

Ein Programm als anderer Benutzer ausführen: heute, mit den Fallen

Für einen Einzelfall genügt der eingebaute Weg. Für alles Wiederholte ein Skript, und die Anmeldedaten nicht ins Skript. Das Muster unten fragt einmal und startet mehrere Programme unter derselben zweiten Identität: der Fall, den das Kontextmenü schlecht bedient.

$cred = Get-Credential BISTRO\svc_report

Start-Process -Credential $cred -FilePath 'mmc.exe'     -ArgumentList 'compmgmt.msc'
Start-Process -Credential $cred -FilePath 'notepad.exe' -ArgumentList 'D:\jobs\notizen.txt'

whoami /all   # IM neuen Prozess ausführen: Identität, Gruppen, Privilegien prüfen

Drei Fehlerbilder machen den Großteil der Probleme aus. Dem Konto ist die lokale Anmeldung verweigert, das Token wird also ausgegeben und die Sitzung nimmt es nicht an. Das Profil existiert nicht und lässt sich nicht anlegen, das Programm startet mit einem temporären Profil und verliert seine Einstellungen beim Beenden. Oder das Programm selbst erzwingt eine Instanz pro Rechner, dann hilft kein korrektes Kennwort zu einem zweiten Fenster.

Der Prüfschritt ist wichtiger, als er aussieht. Ein Prozess kann unter dem richtigen Namen laufen und trotzdem eine Gruppenmitgliedschaft nicht haben, die der Aufrufer erwartet hat, weil Gruppenmitgliedschaften bei der Anmeldung ins Token geschrieben werden. whoami /all im neuen Prozess ist die einzige Prüfung, die zeigt, was wirklich drinsteht.

Was zu vergeben ist, wenn das unter Windows Routine wird

Soll ein Team regelmäßig ein Programm als anderer Benutzer ausführen, hat die haltbare Regelung drei Teile. Der Dienst für sekundäre Anmeldungen bleibt aktiv, denn alles hängt an ihm. Das zweite Konto erhält auf den betroffenen Rechnern das lokale Anmelderecht und sonst nichts, was es nicht braucht. Und Anmeldedaten werden nicht gespeichert. Eine Abfrage je Vorgang ist ein kleiner Preis gegen ein Geheimnis, das die Aufgabe überlebt.

Wo eine Aufgabe wirklich ohne anwesende Person laufen muss, gehört sie gar nicht in diesen Mechanismus. Eine geplante Aufgabe mit eigenem Dienstkonto oder ein Dienst liefern dasselbe Ergebnis mit nachvollziehbarem Eigentümer und ohne interaktives Kennwort irgendwo. Auch die nötigen Rechte unterscheiden sich, und das ist der Punkt, der vor dem Anlegen eines Kontos gehört: ein interaktiver Start braucht Lokal anmelden auf dem Zielrechner, eine geplante Aufgabe Anmelden als Stapelverarbeitungsauftrag, ein Dienst Anmelden als Dienst. Ein Konto, das ausschließlich unbeaufsichtigte Arbeit erledigt und trotzdem das interaktive Recht hat, hat einen Zugang, den keine seiner Aufgaben braucht.