Gibt es eine Möglichkeit, eine Anwendung als anderer aktuell angemeldeter Benutzer auszuführen, ohne dessen Kennwort zu benötigen?

Gibt es eine Möglichkeit, eine Anwendung als anderer aktuell angemeldeter Benutzer auszuführen, ohne dessen Kennwort zu benötigen?

Ich möchte „psexec“ über ein LAN verwenden, um einen Befehl als anderer Benutzer auszuführen, der gleichzeitig am System angemeldet ist.

Mit anderen Worten: Ich möchte „psexec“ mit den integrierten Anmeldeinformationen des Administratorkontos verwenden, um ein Programm auf Bobs Desktop auszuführen. Dieses Programm muss glauben, dass es von Bob mit seinen Anmeldeinformationen gestartet wurde. Da ich das Administratorkonto verwende, möchte ich die Notwendigkeit von Bobs Passwort hierfür umgehen (vielleicht mit „runas“).

Bearbeiten 1

Erläuterungen:

Ich habe bereits Zugriff auf das System, da ich das Administratorkonto besitze.

Ich habe keine Lust, ständig einen Agenten/Dienst/eine EXE im Hintergrund laufen zu lassen.

Dies ist eine Heimkonfiguration.

Ich habe an so etwas gedacht:http://reboot.pro/files/file/237-runassystem-and-runfromtoken/sondern auf jeden anderen Benutzer angewendet.

Ich möchte ein Programm wie beispielsweise ein Spiel oder einen E-Mail-Client starten können, das Dateien in benutzerspezifischen Pfaden speichert.** Die Ausführung als Administrator wäre daher nicht effektiv, da das Programm das Datenprofil des Administrators und nicht das von Bob (der angemeldet ist) laden würde.

Mein ultimatives Ziel besteht darin, den Befehl „whoami“ starten zu können und die Meldung zu erhalten, dass ich der angemeldete Benutzer bin.

Aktualisieren

Ich konnte eine „cmd.exe“ als SYSTEM abrufen und dann mithilfe von RunFromToken eine Instanz als mein Konto (kennwortgeschützt) abrufen. Ich werde das weiter testen.

Antwort1

Nein. Damit wäre der Sinn der individuellen Sicherheit völlig umgangen.

Ich möchte jedoch hinzufügen, dass Sie, wenn Sie Zugriff auf ein Bereitstellungssystem wie SCCM haben, ein Paket nur ausführen können, wenn der Benutzer angemeldet ist, und es dann im Kontext des Benutzers ausgeführt wird. Sie können das Paket auch als Teil eines Anmeldeskripts ausführen, das ebenfalls im Kontext des Benutzers ausgeführt wird.

Antwort2

Alle diese Antworten sind richtig, soweit es um die Identitätsübernahme eines Benutzers über das Netzwerk geht. Unter bestimmten Bedingungen können Sie jedoch die Identität eines lokalen Benutzers annehmen, ohne dass ein Kennwort erforderlich ist:

  1. Sie müssen Mitglied der lokalen Administratorgruppe sein.
  2. Sie können sich nur als ein anderer Benutzer ausgeben, der aktuell am System angemeldet ist.
  3. Die Benutzerimitation ist auf das lokale System beschränkt. Sie können die Identität eines Benutzers auf einem Remote-System nicht imitieren, ohne sich zuvor als Mitglied der lokalen Administratorgruppe am Remote-System angemeldet zu haben.

Dies ist zulässig, weil Windows das PRIVILEG zum Impersonieren lokal angemeldeter Benutzer an SYSTEM und lokale Administratoren delegiert. Informationen zu diesem PRIVILEG finden Sie unter Lokale Gruppenrichtlinie > Lokale Richtlinien > Zuweisen von Benutzerrechten > Impersonieren eines Clients nach Authentifizierung.

Ein mir bekanntes Tool, mit dem Sie dies tun können, ist Process Hacker 2. Führen Sie das Tool als Administrator aus und suchen Sie einen Prozess, der als der Benutzer ausgeführt wird, dessen Identität Sie annehmen möchten. Klicken Sie mit der rechten Maustaste darauf, wählen Sie „Verschiedenes“ > „Als dieser Benutzer ausführen …“ und geben Sie dann den Binärpfad ein, den Sie als dieser Benutzer ausführen möchten, z. B. cmd. CMD wird dann als dieser Benutzer geöffnet, ohne dass Sie nach dem Kennwort dieses Benutzers gefragt werden.

Antwort3

Das können Sie nicht tun und zwar aus verdammt guten Gründen.

Wenn dies möglich wäre, wäre das der Heilige Gral für jeden Virus.
Auf einem Windows-Computer laufen immer mehrere Prozesse unter mehreren Administratorkonten (wie etwa LocalSystem- und NetworkSystem-Konten, um nur zwei zu nennen).
Wenn Ihre Anforderung erfüllt werden könnte, könnten beliebige Prozesse neue Prozesse in diese Konten einfügen: Sie könnten Ihr System auf keinen Fall vor Viren schützen. (Jeder beliebige Prozess meint wörtlich, was er sagt: Dazu gehören auch Viren!)

Weitere Probleme sind Datenschutz und Verantwortlichkeit.
Wenn Sie den Vorgang so vortäuschen können, als sei er von einem anderen Benutzer ausgeführt worden, können Sie auf die Daten dieses anderen Benutzers zugreifen. Der Datenschutz ist dahin.
Und es gibt keine Möglichkeit mehr festzustellen, ob etwas tatsächlich von diesem Benutzer oder von jemandem getan wurde, der sich als dieser ausgibt. Das heißt, Sie können nicht mehr zuverlässig nachvollziehen, wer was getan hat. Sie verlieren die Verantwortlichkeit, was bei Systemen, die Compliance-Vorschriften einhalten müssen, wie z. B. medizinischen Systemen, ein großes Problem darstellt.

Dies sind also sehr gute Gründe, die Umgebungen der Konten voneinander zu isolieren. (Es gibt noch eine ganze Menge mehr, aber das geht über den Rahmen dieser Frage hinaus.)

Antwort4

Wie in anderen Antworten erwähnt, möchten Sie das wahrscheinlich wirklich nicht tun. Wenn es so einfach wäre, könnte ich beispielsweise einen Benutzer zwingen, eine illegale Website zu laden, woraufhin er gefeuert und verhaftet wird. Nicht einmal Administratoren sollten über diese gottgleiche Macht verfügen.

Wenn Sie wirklich nur herausfinden möchten, wer derzeit bei einem Computer (lokal oder remote) angemeldet ist, ziehen Sie das Dienstprogramm „psloggedon“ von MS TechNet (ehemals SysInternals) in Betracht:https://technet.microsoft.com/en-us/sysinternals/bb897545.aspx

Wenn Sie eine Aufgabe immer noch als Benutzer ausführen müssen, sollten Sie sich die Möglichkeit ansehen, Aufgaben bei der Anmeldung auszuführen. Aus Sicherheitsgründen wird dies natürlich immer noch zu Ihnen zurückverfolgt, aber Windows wird trotzdemlaufendie Aufgabe, als ob Sie der betreffende Benutzer wären.

verwandte Informationen