Windows-Dienst, Notification, Zugriff verweigert

[Delrabe]

Hallo,

auf einem Windows 10-Rechner verwalte ich ein komplexes und umfangreiches Delphi-Projekt mit Datenbank-Anbindung und einem funktionierenden Update-Mechanismus. Zusätzlich hätte ich gerne einen Windows-Dienst, der bei Anwendern gelegentlich prüft, ob Programm-Updates vorhanden sind, und dies ggf. meldet. Dies ist in erster Linie gedacht für Sys-Admin's, die Software auf Client-Rechnern verwalten, und für sporadische User, die gerne einmal ein Update verpassen.

Inzwischen habe ich den Dienst (TService-Anwendung) und einen Dienst-Monitor (Standard-Anwendung) erstellt. Mit dem Dienst-Monitor kann man Dienst-Details einstellen und die Standard-Aktionen (Dienst installieren, starten usw.) vornehmen. Alles funktioniert wie gewünscht, nur kann der Dienst derzeitig keine Meldung an den User schicken.

Dies hatte ich natürlich als erstes geprüft, und das war via TNotificationCenter, TNotification und PresentNotification sehr einfach. In einer normalen Anwendung funktioniert das auch ohne Probleme, nur beim Dienst erfolgt immer die Meldung "Zugriff verweigert".

Inzwischen habe ich zusätzlich eine kleine Anwendung erstellt, die unsichtbar das Melden übernimmt und die Aktionen protokolliert. Dieses Notify-Programm ruft man auf und übergibt dabei die Meldungsdaten als Parameter. Es ergibt sich dabei dasselbe Verhalten. Beim Aufruf aus einer "normalen" Anwendung funktioniert die Sache, beim Aufruf aus dem Dienst heraus wird bei "NotificationCenter.PresentNotification" wieder der "Zugriff verweigert".

Ich habe mir inzwischen schon den Wolf gegoogelt nach möglicherweise fehlenden Rechten sowie Besonderheiten bei Notification und Windows-Diensten, habe aber nichts gefunden. Ich hoffe, dass mir jemand helfen kann.

[himitsu]

Das hat nichts mit Notifications zu tun.

Interactive Dienste sind seit Jahrzehnten grundsätzlich verboten.
Ebenso ist der Zugriff aus einer anderen Session/Desktop nicht erlaubt. (ist im Printip das Gleiche)

Interaktiv = mit dem Nutzer reden/interagieren


Rate mal, warum viele andere Anwendungen auch eine extra NotifyApp im aktuellen Nutzerkontext starten, oder beschissener Weise dauerhaft nutzlos mitlaufen lassen?
CreateProcessAsUser
CreateProcessWithLogonW
CreateProcessWithTokenW
usw.


Man kann zwar via Impersonation auch den eigenen Prozess einen Thread des eigenen Prozesses in einen anderen Kontext verschieben, aber das hilft nicht bei Allem und hat sowieso einige Nachteile.




OpenInputDesktop
WTSGetActiveConsoleSessionId
via WMI abfragen welcher Nutzer im aktiven Desktop in der aktiven Konsole eingeloggt ist. (nicht Konsole wie Konsole aka CMD, sondern wie Konsole aka Monitor+Tastatur/Maus)
oder sonstwas


[add]
https://stackoverflow.com/questions/...t-user-session
https://www.delphipraxis.net/101151-...-tservice.html

[Delrabe]

Hallo himitsu,

vielen Dank für die schnelle Antwort. Damit weiß ich jetzt, wo genau der Schuh drückt und wie man das Problem prinzipiell beheben kann.

Eine Notify-App habe ich ja schon benutzt; es geht jetzt wohl darum, diese richtig aufzurufen. Leider hat der erste Versucht mittels "SvcLaunchAppInCurrUserSession" aus
https://stackoverflow.com/questions/...t-user-session
auch nicht funktioniert. Das muß ich erst noch analysieren und ggf. Alternativen ausprobieren.

Ich melde mich, sobald ich ein Ergebnis habe.

[Sinspin]

Du brauchst eine Kommunikation zwischen den beiden Programmen die über Sessions (virtuelle Desktops) hinweg funktioniert. Dafür hat Windows Schnittstellen geschaffen die man verwenden muss.
Wir verwenden zur Kommunikation eine NamedPipe.
Der Service ist der PipeServer und muss der Pipe das Recht (eine Custom Security Description) geben, mit anderen Programmen außerhalb der eigenen Session reden zu können.

[Delrabe]

Hallo,

kurzer Zwischenbericht: Offenbar geht es darum, das Notify-Programm aus dem Dienst heraus in geeigneter Weise aufzurufen. Dafür habe ich anhand der Beispiele im Netz eine Variante von "ExecuteAsUser" entwickelt. Damit verschwindet bei dem Notify-Aufruf das frühere "Zugriff verweigert". Leider wird jetzt beim Aufruf von "CreateProcessAsUser" der Fehler "Der angeforderte Vorgang erfordert erhöhte Rechte" gemeldet. Die betreffenden Prozeduren befinden sich alle in der beiligenden Unit. Der kritische Punkt ist vielleicht "TExecUsrRec.CrtFlags". Damit habe ich nicht viel Erfahrung. Möglicherweise muß man auch noch etwas beim TStartupInfo einstellen.

Zusatz-Info: Insgesamt sind 3 Delphi-Programme beteiligt; die Dienst-Anwendung, das Monitor-Programm und die kleine Notify-App. Bei den ersten beiden verlange ich Admin-Rechte, bei der Notify-App ist das wohl nicht nötig. Ich weiß aber auch nicht, über welche Rechte der Dienst verfügt, wenn er über "Dienst.exe /Install" aus dem Monitor-Programm erstellt wird.

[peterbelow]

Zitat von Delrabe:

Ich weiß aber auch nicht, über welche Rechte der Dienst verfügt, wenn er über "Dienst.exe /Install" aus dem Monitor-Programm erstellt wird.

Per default läuft ein Service unter dem System-Account, man kann ihm aber über das Service-Applet auch einen anderen Account zuordnen.

[Delrabe]

Hallo,

@Sinspin: Danke für den Hinweis, die Kommunikation zwischen dem Dienst und der Notify.App ist in meinen Augen kein Problem. Die Daten könnten z.B. in einer Datei vom ini-Typ stehen, wo der Dienst unter [MELDUNG] die gewünschten Meldungs-Daten einträgt und die Notify.App anschließend unter [NOTIFY] das Ergebnis und ggf. die Fehlermeldung einträgt. Der Dienst könnte bei Bedarf eine solche Datei erstellen und beim Aufruf der Notify.App diese Datei als Parameter übergeben.

Das Problem ist aber genau dieser Aufruf der Notify.App aus dem Dienst heraus. Das ist offenbar direkt nicht gestattet, weshalb wohl ein Aufruf als "aktueller User" bereitgestellt wird. Leider funktioniert der derzeitig nicht.

Im Detail: Ich verschaffe mir das "Token" des aktuellen Users, wobei "WtsGetActiveConsoleSessionID" und "WTSQueryUserToken" verwendet werden, und rufe danach "CreateProcessAsUser" mit den entsprechenden Parametern auf (vgl. den Quellcode). Leider bekomme ich jetzt eine Fehlermeldung, die wohl bedeutet, dass Admin-Rechte fehlen. Das verstehe ich nicht. Für den Aufruf der Notify.App sind eigentlich keine Admin-Rechte notwendig. Ich selbst bin als Admin angemeldet, nicht als Sys-Admin, aber was spielt das für eine Rolle? Hier wäre ich dankbar für Erläuterungen.

Inzwischen habe ich eine Variante mit "TImpersonateUser" aus dem Netz eingebaut, die wahlweise benutzt werden kann (vgl. die neue Version des Quellcodes). Die funktioniert aber auch nicht, Meldung "Eine Anmeldeanforderung enthielt einen unzulässigen Wert für den Anmeldungstyp" (ERROR_INVALID_LOGON_TYPE). Das liegt möglicherweise daran, dass man zwar den aktuellen User bestimmen kann, aber man kennt natürlich nicht sein PW. Mein Verdacht ist, dass diese Möglichkeit für spezielle Fälle benutzt wird, wo man in einem Programm ein PW abfragt, um Zugriff auf spezielle Features zu ermöglichen.

@peterbelow: Danke für den Hinweis.

@Sinspin: Bei den "Windows Schnittstellen", die man verwenden sollte, wäre ich dankbar für ein paar zusätzliche Info's. So kann ich damit nichts anfangen.

[QuickAndDirty]

Ich mag das Problem total falsch verstehen,
aber spricht irgendetwas gegen ein Programm das in der Systemtray mit läuft und sich im Autostart in der registry einrichtet und dann den Dienst überwacht und von dem Dienst auch mitgeteilt bekommt, wenn es mal ne Meldung Anzeigen soll?
Ist das nicht mehr "state of the art"?

[Sinspin]

Das ist es, wo ich mich jedesmal frage, warum soll der Dienst was starten?
Das macht entweder die Verwaltungsanwendung mit oder man schreibt was Fensterloses fürn Systray was die Meldungen generiert.

Und Kommunikation via INI? Ich weis nicht. Ich bin auch noch aus den vorgen Jahrtausend. Aber das ist schon ne ganz spezielle Idee.
Das nennt sich "Named Pipes" dazu hat Micosoft ne ganze gute docu.

[himitsu]

Genau andersrum.

Warum soll jeder Dreck massenhaft Notify-Programme starten und dauerhaft laufen lassen,
anstatt, nur wenn benötigt, kurzzitig Jenes zu starten?

Auf einem Terminal-Server wird es noch schlimmer, wenn dutzende Leute eingeloggt sind, bei JEDEM dutzende Notify-Programme laufen,
anstatt nur das eine Programm, welches "jetzt" was sagen will, bei aktiven Usern (vielleicht sogar nur bei Admins)



Klar, Programme, welche im Tray ständig einen Status anzeigen müssen sollen, da ist es OK.