Frage

Ich habe einen kleinen Service (Plain Win32) geschrieben und ich möchte wissen, ob es möglich ist, mehrere Instanzen davon durchzuführen, wenn mehrere Benutzer angemeldet sind.

Nehmen wir an, wir haben Usera und UserB für Usera. Der Dienst würde sich als "Domain Usera" anmelden und für den BenutzerB wird sich der Dienst als "Domain UserB" anmelden - dies stammt natürlich von derselben ausführbaren Datei. Ich kann die Anmeldung mithilfe der Funktion ayagesServiceConfig () dynamisch ändern, aber es ändert es systemweit, während ich möchte, dass jeder Benutzer seine eigene Kopie des Dienstes nur für ihn läuft.

Vielen Dank im Voraus für alle Hinweise.

War es hilfreich?

Lösung

Win32-Dienste sind so konzipiert, dass sie systemweit sind und mit dem Ausführen beginnen, bevor ein Benutzer angemeldet ist. Wenn Sie möchten, dass etwas pro-user-Basis ausgeführt wird, ist es wahrscheinlich besser, es als reguläre Anwendung zu entwerfen und aus dem Start des Benutzers auszuführen Gruppe.

Andere Tipps

Ist es möglich, dass der Service untergeordnete Prozesse erstellt, die dann die Benutzeranmeldeinformationen annehmen (oder mit ihnen gestartet werden)? Auf diese Weise sind Sie immer noch auf einen einzigen Instanz des Dienstes beschränkt, aber es ist in der Lage, seine Arbeitsplätze pro Benutzer gleich zu erledigen. IIRC Der Windows -Task -Scheduler -Dienst erledigt dies.

Das gesamte Konzept eines Dienstes ist, dass er gestartet wird, bevor ein Benutzer überhaupt angemeldet ist. Selbst wenn dies möglich wäre, könnten Sie nicht zwischen Usera und UserB wählen, wenn der Dienst beginnt, da noch keiner von ihnen angemeldet ist.


Eine mögliche Richtung wäre, dass der Dienst als System ausgeführt wird und alle paar Minuten prüfen, ob ein Benutzer angemeldet ist, wenn es diesen Benutzer ausbleibt und dieses Zeug erledigt.

Ja, das klingt eng (ich beantworte einen Kommentar von Greg, aber Kommentare sind zu kurz, um meine Antwort anzupassen).

Ich kenne die Liste der Benutzer vorher nicht, aber es gibt eine GUI -Steuerungsanwendung, mit der für jeden Benutzer Benutzername-/Passwortpaare eingegeben werden können. Also würde Usera sich anmelden, die Anwendung ausführen, seine Anmeldeinformationen eingeben und dies würde dies nutzen. Gleichzeitig (nachdem Usera angemeldet hat, der Dienst wird jedoch immer noch mit den Anmeldeinformationen von Usera ausgeführt) UserB -Protokolle verwendet, die App verwendet, und eine andere Kopie des Dienstes wird als Anmeldung auf Benutzerb ausgeführt. Gleichzeitig werden Usera- und UserB -Dienste ausgeführt.

Ist das möglich?

Sie möchten wahrscheinlich die Benutzer ausgeben. Schauen Sie sich einige Referenzen an, die ich mit einer schnellen Google -Suche hier gefunden habe:

Es hört sich so an, als hätten Sie tatsächlich zwei verschiedene, widersprüchliche Anforderungen an das Timing und die Identität.

  1. Führen Sie als jeder im Benutzer angemeldete Ausführen
  2. Führen Sie automatisch aus, auch wenn kein Benutzer angemeldet ist.

Keine Möglichkeit, dies trivial zu tun, sondern in Betracht, Ihr Programm in einen Dienst zu wickeln. Das Programm wird normal im Start für jeden Benutzer ausgeführt (entweder durch den Startordner oder den TaSkScheduler) und) und zusätzlich Erstellen Sie einen Dienst, um Ihre App als Systembenutzer (oder einen anderen Benutzer, den Sie definieren) auszuführen.
Da Sie auch die App benötigen (Sie erwähnen dies in den Kommentaren), um auch nach dem Abmelden weiterhin als Enduser auszuführen, können Sie den Service für Sie verwalten.

Dies ist jedoch möglicherweise nicht die beste Idee, da der Benutzer immer noch effektiv angemeldet ist. Dies kann zahlreiche Nebenwirkungen haben, einschließlich Sicherheit, Leistung (zu viele Benutzer gleichzeitig angemeldet ...) usw.

Sie können eine Serviceanwendung und eine Nicht-Service-Anwendung (normale) Anwendung erstellen und diese über IPC (zugeordnete Datei, Rohrleitungen, MailStolts ... Sie nennen) kommunizieren.

Auf diese Weise lösen Sie alle Probleme.

Hinweis: Die gleiche Anwendung kann sich anders verhalten - wenn sie als Prozess gestartet werden und von einem Benutzer gestartet werden, aber am Ende ist es dasselbe, haben Sie immer noch 2 Anwendungen (egal ob Sie nur eine ausführbare Datei haben).

Das Laufen mit verschiedenen Konten ist möglich. In der Tat ist dies üblich. Siehe svchost.exe, die eine Reihe von Betriebssystemdiensten implementiert.

Ich verstehe einfach nicht, wie Sie bestimmen, welche Konten. In einem großen Unternehmen sind viele PCs eingerichtet, sodass alle mehr als 100.000 Mitarbeiter es verwenden können. Sie möchten Ihren Service nicht als angemeldete Benutzer ausführen, noch können Sie ihn für alle 100.000 Benutzer ausführen. Für welche Konten muss ich fragen?

Ein Windows -Prozess kann nur mit den Berechtigungen eines einzelnen Benutzers gleichzeitig ausgeführt werden. Dies gilt für Dienstleistungen und andere Prozesse. Mit genügend Berechtigungen ist es möglich, zwischen verschiedenen Benutzern mithilfe von Identitätswechsel "zu" wechseln ". Das häufigste Muster für das, was Sie versuchen zu tun, ist eine Instanz eines privilegierten Dienstes zu haben, in dem sich Ereignisse anmelden/anmelden und sich anmelden und Kinderprozesse entsprechend erstellen, wobei jede von ihnen die protokollierten Benutzer ausgibt. Das Muster vereinfacht auch die Benutzeroberfläche, da jeder Prozess auf jedem separaten Benutzerdesktop ausgeführt wird, als wäre es eine reguläre Anwendung.

Wenn Sie den Code des privilegierten Dienstes so einfach wie möglich halten, hat dieses Muster den zusätzlichen Vorteil, dass Sie die Angriffsfläche Ihres Codes minimieren. Wenn ein Benutzer ein Sicherheitsproblem auf der Seite "Als Benutzer ausführen" Ihres Dienstes findet, handelt es sich nicht um ein Problem, während Sicherheitsprobleme in den privilegierten Diensten zu einer Eskalation von Privilegien führen können. Tatsächlich sind vor Vista -privilegierte Dienste, die eine Windows -Nachrichtenverarbeitungsschleife implementieren Zerschmetterte Angriffe, was du dir bewusst sein solltest, was du versuchst.

Sie möchten, dass dies die ganze Zeit ausgeführt wird, also möchten Sie einen Service.

Sie möchten etwas, das jeden Benutzer verfolgt, also möchten Sie eine Anwendung, die in der Benutzersitzung ausgeführt wird und mit dem Dienst mit dem Dienst mit den Namen Pipes oder DCOM oder was auch immer zu Ihren Anforderungen entspricht).

Sie benötigen nicht mehrere Instanzen Ihres Dienstes. Aus der Beschreibung Ihres Problems sieht es so aus, als ob Sie einen Dienst benötigen, der sich als Benutzer ausgeben und Jobs in ihrem Namen ausführen kann.

Sie können dies tun, indem Sie ein COM -Objekt implementieren, das in einem Dienst gehostet wird. Ihre Client -Anwendung (die der Endbenutzer ausführt) nennt Cocrreateinstanceex auf Ihrem CLSID. Dies würde dazu führen, dass Ihr COM -Objekt in Ihrem Service erstellt wird. Anschließend kann die Anwendung eine Methode auf einer Ihrer Schnittstellen verwenden, um die gesammelten Benutzeranmeldeinformationen an das COM -Objekt zu übergeben (obwohl ich vorsichtig sein würde, Anmeldeinformationen zu sammeln und stattdessen zu sehen, ob ich stattdessen das Benutzer -Token übergeben kann). Das COM-Objekt, das im Kontext des Dienstes ausgeführt wird, kann dann LogonUser () aufrufen, um sich beim Benutzer anzumelden und ihn auszugeben, damit es alles in ihrem Namen tun kann (wie das Finden des örtlichen AppData-Ordners des Benutzers :-)). Andere Antworten haben gute Links, um Benutzer mit Anmeldeinformationen oder Token auszugeben.

Wenn Sie sich mit COM wohl fühlen, würde ich vorschlagen, dass Sie Ihre Objekte als Multithread (im MTA leben) erstellen, damit ihre Ausführung nicht durch COM serialisiert wird. Wenn nicht, wäre das Standardmodell für ein einzelne Thread gut genug für Sie.

Der Visual Studio ATL -Assistent kann das Skelett eines COM -Objekts erzeugen, das in einem Dienst lebt. Sie können hier auch über das Implementieren von Windows -Service mit ATL lesen: hier: http://msdn.microsoft.com/en-us/library/74y2334x(vs.80).aspx

Wenn Sie COM überhaupt nicht kennen, können Sie andere Kommunikationskanäle verwenden, um die Anmeldeinformationen an Ihren Dienst zu übergeben.

Sobald Ihr Dienst die Anmeldeinformationen erhalten hat, muss die gesamte Arbeit im Namen des Benutzers in einem Hintergrund -Thread ausgeführt werden, um die Anwendung nicht als Benutzer zu blockieren.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top