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:

Zitat von Delrabe (Beitrag 1525619)

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.

[Sinspin]

Zitat:

Zitat von himitsu (Beitrag 1525712)

Genau andersrum.

Dann erleuchte uns:gruebel:, anstatt noch mehr heiße Luft zu produzieren!

Wie geht es dann richtig?

[QuickAndDirty]

Ich bin zwar nicht Himitsu...aber vielleicht denkt er an sowas:
In Windwows 11 gibts ein Windows Notification Center ... ich denke(Ich weiß es nicht!!!) da haben sie endlich mal eine Lösung geschaffen die vergleichbar mit Android oder IOS ist, wo man Pushnotofications auf den Desktop zaubern kann?

Aber auf älteren Windosen muss man mit der Systray weiter machen...

[Delrabe]

Hallo,

danke für die Anworten. Und sorry, ich bin zwar ein versierter Delphi-Entwickler, habe aber auf diesem Feld noch Defizite.

Wenn die Notify-App also ebenfalls permanent gestartet ist und es "nur" darum geht, dass der Dienst die Notify-App über ein anstehendes Update informiert, dann verstehe ich natürlich auch den Einsatz einer NamedPipe. Und bevor ich mich darin vertiefe, wie in etwa sieht das auf der Seite der Notify-App aus? Die App muß wohl beim Start ein MS-Objekt erzeugen, in dem ein entspr. Handle angefordert wird. Aber wie geht es jetzt weiter? Gibt es dabei irgendeine Form von Event/Message, auf die die App. nur reagieren muß, oder muß die App. ähnlich wie beim Dienst vorgehen, also permanent die Update-Situation prüfen und dann eine kleine Zeit (1000 Milli.Sek.) schlafen.

Inzwischen habe ich allerdings eine andere Idee. Man könnte auch ganz auf einen Dienst verzichten, und stattdessen die Arbeit von einer Kontroll-App. erledigen lassen, die unsichtbar im Hintergrund läuft und im Autostart eingetragen ist, ähnlich wie das jetzt für die NotifyApp vorgeschlagen wurde. Diese Kontroll-App müsste einen Kontroll-Thread erstellen und starten, der permanent eine anstehende Aktion prüft, ggf. einen Client-Thread zur Durchführung startet und anschließend ein kleine Zeit pausiert. Bei dieser Konstruktion sollte das Notify-Problem entfallen, oder?

Ich sehe nur ein Problem, wenn die Sache auf einem Client-Rechner läuft und der angemeldete User nur über geringe Rechte verfügt. Die Kontroll-App. müsste vom Sys-Admin so eingerichtet/installiert werden, dass sie über das Recht verfügt, Daten von unserem Server herunterzuladen, bzw. vorerst würde sogar der Download der entsprechenden Konfig.-Textdatei genügen. Ich weiß leider nicht, was da möglich ist.

[himitsu]

Hab ich doch beschrieben?
Kannst'e lesen?

* du bist dafür, dass jeder eine App unsichtbart oder im Tray laufen lässt, selbst wenn die meistens nicht genutzt wird

* ich bin dafür, dass man diese "permanenten" Nachrichten-Apps abschafft und stattdessen der Dienst im Falle des Anzeigewillens den Prozess zum Anzeigen im aktiven Kontext vorübergehend startet,
damit eben nicht sinnlos tausende Anwendungen aktiv sein müssen.

Und ja, das NotificationCenter ist auch nett.
OK, die Komponente von Embarcadero ist schrott, aber per se muß das Programm nicht dauerhaft laufen, nach der Anzeige dort. Wenn sich die Anwendung/Komponente richtig mit der Notification verbunden hätte, würde Windows unser Programm wieder starten, wenn man auf die Notification klickt und das eigene Programm schon wieder weg war.

[Delrabe]

Hallo,

@himitsu: unabhängig davon, was gut oder schlecht ist, die Hauptfrage ist, was geht und was geht nicht. Bei der Version "Dienst startet Notify.App" besteht das Problem, dies auch wirklich durchzuführen. Wie bereits beschrieben, der Dienst verschafft sich das "Token" des aktuellen Users/Contextes und versucht dann die NotifyApp über "CreateProcessAsUser" zu starten. Dies schlägt leider fehl mit einer Meldung über fehlende Rechte. Möglicherweise muß man bei diesem Aufruf noch zusätzliche Parameter einbauen (SecurityAttributes, ThreadAttributes, Environment), aber da bräuchte ich Hinweise, wie genau das geht. Ich habe im Netz schon viel dazu gelesen, aber keine funktionierenden präzisen Hinweise gefunden.

Es wird im übrigen auch "CreateProcessWithLogonW" vorgeschlagen, aber da weiß ich nicht, wie das "gehen" soll, da man ja das Passwort nicht kennt.

[Delrabe]

Hallo,

irgendwie ging meine Antwort von vor einer Stunde verlustig. Daher noch einmal ein Versuch.

Danke für die Anworten. Und sorry, ich bin zwar ein versierter Delphi-Entwickler, habe aber auf diesem Feld noch Defizite.

Wenn die Notify-App also ebenfalls permanent gestartet ist und es "nur" darum geht, dass der Dienst die Notify-App über ein anstehendes Update informiert, dann verstehe ich natürlich auch den Einsatz einer NamedPipe. Und bevor ich mich darin vertiefe, wie in etwa sieht das auf der Seite der Notify-App aus? Die App muß wohl beim Start ein MS-Objekt erzeugen, in dem ein entspr. Handle angefordert wird. Aber wie geht es jetzt weiter? Gibt es dabei irgendeine Form von Event/Message, auf die die App. nur reagieren muß, oder muß die App. ähnlich wie beim Dienst vorgehen, also permanent die Update-Situation prüfen und dann eine kleine Zeit (1000 Milli.Sek.) schlafen.

Inzwischen habe ich allerdings eine andere Idee. Man könnte auch ganz auf einen Dienst verzichten, und stattdessen die Arbeit von einer Kontroll-App. erledigen lassen, die unsichtbar im Hintergrund läuft und im Autostart eingetragen ist, ähnlich wie das jetzt für die NotifyApp vorgeschlagen wurde. Diese Kontroll-App müsste einen Kontroll-Thread erstellen und starten, der permanent eine anstehende Aktion prüft, ggf. einen Client-Thread zur Durchführung startet und anschließend ein kleine Zeit pausiert. Bei dieser Konstruktion sollte das Notify-Problem entfallen, oder?

Ich sehe nur ein Problem, wenn die Sache auf einem Client-Rechner läuft und der angemeldete User nur über geringe Rechte verfügt. Die Kontroll-App. müsste vom Sys-Admin so eingerichtet/installiert werden, dass sie über das Recht verfügt, Daten von unserem Server herunterzuladen, bzw. vorerst würde sogar der Download der entsprechenden Konfig.-Textdatei genügen. Ich weiß leider nicht, was da möglich ist.

[himitsu]

[ups]

[Sinspin]

Der Name einer Named Pipe ist beiden Programmen bekannt. Über den Name kommt die Verbindung zustande. Der Dienst muss die Named Pipe erzeugen und ihre Rechte anpassen, sonst ist sie außerhalb der des Dienst Desktops sichtbar/erreichbar.
Ich verwende eine Komponente von NSoftware, die den Aufwand für die Nutzung etwas reduziert. Da gibt es sicherlich auch noch andere Lösungen. Oder eben den direkten weg.

Das ist halt immer die Frage, reicht eine Anwendung via Autostart? Oder ist es wichtig das auch in Fällen in denen kein Nutzer angemeldet ist, aber es Zeit wird die Aufgabe zu erledigen, die Aufgabe erledigt werden kann. Dienste laufen mit dem Rechner, Anwenderprogramme erst mit Nutzeranmeldung.

[Delrabe]

Hallo Sinspin,

in meinem Fall würde die Autostart-Version reichen. Sie muß nur funktionieren, insbesondere wenn der angemeldete User nicht über die notwendigen Rechte (z.B. Download) verfügt.

[himitsu]

@Delrabe
Dass es geht, beweisen ja mehrere Programme, welche die NotifyApp aus dem Server starten.

Auch kann man im Server einen neuen Thread erstellen, ihn in einen anderen Kontext verschieben und von dort aus auf den Nutzerdesktop zugreifen.
z.B. TeamViewer soll das intern tun, um z.B. die UAC-Passorteingabe anzeigen zu können.

[QuickAndDirty]

Zitat:

Zitat von himitsu (Beitrag 1525748)

@Delrabe
Dass es geht, beweisen ja mehrere Programme, welche die NotifyApp aus dem Server starten.

Auch kann man im Server einen neuen Thread erstellen, ihn in einen anderen Kontext verschieben und von dort aus auf den Nutzerdesktop zugreifen.
z.B. TeamViewer soll das intern tun, um z.B. die UAC-Passorteingabe anzeigen zu können.

Ich bin davon überzeugt, dass du recht hast, dass man auf eine Systray-Autostart-App verzichten kann, wenn man es schafft aus dem Dienst heraus eine Meldung auf aktiven Sessions anzeigen kann.
Wie sieht eine solche Methode aus?

Delphi-Quellcode:

Procedure ShowMessageInAllInteractiveSessions(aMessage:String);
Begin
// was muss hier hin damit ein Dienst auf allen interaktiven Sesssions den Messagetext anzeigen kann?
end;

[QuickAndDirty]

Zitat:

Zitat von Delrabe (Beitrag 1525747)

Hallo Sinspin,

in meinem Fall würde die Autostart-Version reichen. Sie muß nur funktionieren, insbesondere wenn der angemeldete User nicht über die notwendigen Rechte (z.B. Download) verfügt.

Die Sache ist die, dass man rechte normalerweise in diensten konserviert... sprich..der Admin installiert das Programm...und das Programm installiert einen Dienst der die Sachen ausführt die mehr rechte brauchen.
Der Installer der mit admin rechten läuft (oder eine Erststart der mit Admin rechten läuft) setzt dann den ACL(SDDL) des Dienstes so, dass unprivilegierte Benutzer ihn starten können.

Delphi-Quellcode:

// der erste ist der SD den der Dienst normalerweise hat wenn man ihn nicht anpasst.
//ACL (SDDL )
SECURITY_DESCRIPTOR_STANDARD = 'D:' +
  '(A;;CCLCSWRPWPDTLOCRRC;;;SY)' +         // default permissions for local system
  '(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)' + // default permissions for administrators
  '(A;;CCLCSWLOCRRC;;;AU)' +               // default permissions for authenticated users
  '(A;;CCLCSWRPWPDTLOCRRC;;;PU)' +         // default permissions for power users
  '(A;;CCDCLCSWRPWPDTLOCRSDRC;;;BU)'+      // Built IN Users
  '(A;;RP;;;IU)';                          // added permission: start service for interactive users

SECURITY_DESCRIPTOR_ALLOW_START_BY_USER = 'D:' +
  '(A;;CCLCSWRPWPDTLOCRRC;;;SY)' +         // default permissions for local system
  '(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)' + // default permissions for built-in administrators
  '(A;;CCLCSWRPLOCRRC;;;IU)'+              // permissions for interactively logged-on user   von MozillaMaintainance und ChromeElevation
  '(A;;CCLCSWRPLOCRRC;;;SU)'+              // permissions for service logon user  von MozillaMaintainance und ChromeElevation
  '(A;;CCDCLCSWRPWPDTLOCRSDRC;;;BU)'+      // permissions for built-in users
  '(A;;CCLCSWRPLOCRRC;;;AU)' +             // default permissions for authenticated users
  '(A;;CCLCSWRPWPDTLOCRRCRP;;;PU)';        // default permissions for power users

const
  advapi32 = 'advapi32.dll';
  {$IFDEF UNICODE}
  AWSuffix = 'W';
  {$ELSE}
  AWSuffix = 'A';
 {$ENDIF UNICODE}
function ConvertStringSecurityDescriptorToSecurityDescriptorA; external advapi32 name 'ConvertStringSecurityDescriptorToSecurityDescriptorA';
function ConvertStringSecurityDescriptorToSecurityDescriptorW; external advapi32 name 'ConvertStringSecurityDescriptorToSecurityDescriptorW';
function ConvertStringSecurityDescriptorToSecurityDescriptor; external advapi32 name 'ConvertStringSecurityDescriptorToSecurityDescriptor' + AWSuffix;


Procedure SetServiceSecurityDescriptor(ServiceName,Permission:String);// in ServiceAfterInstall ausführen da hat man immer Admin Rechte.
var
  SA: TSecurityAttributes;
  SvcMgr,SvcHandle: SC_HANDLE;
Begin
  SA.nLength := SizeOf(SA);
  SA.bInheritHandle := True;
  if not ConvertStringSecurityDescriptorToSecurityDescriptor(PWideChar(Permission),
                                                         1,
                                                         SA.lpSecurityDescriptor,
                                                         nil
                                                         ) then RaiseLastOSError;
{$IF DEFINED(CLR)}   //A.R. CLR = Common Language Runtime = .NET
  SvcMgr := OpenSCManager('', nil, SC_MANAGER_ALL_ACCESS);
{$ELSE}
  SvcMgr := OpenSCManager(nil, nil, SC_MANAGER_ALL_ACCESS);
{$ENDIF}
  if SvcMgr = 0 then RaiseLastOSError;
  try
    SvcHandle := OpenService(SvcMgr, PWidechar(ServiceName)  , SERVICE_ALL_ACCESS);
    if SvcHandle = 0 then RaiseLastOSError;
    try
      SetServiceObjectSecurity(SVCHandle,DACL_SECURITY_INFORMATION,SA.lpSecurityDescriptor);
    finally
      CloseServiceHandle(SvcHandle);
    end;
  finally
    CloseServiceHandle(SvcMgr);
  end;
  LocalFree(HLOCAL(SA.lpSecurityDescriptor));
end;

Eine ander Möglichkeit Rechte zu konservieren ist es einen Geplantentask im Taskscheduler zu hinterlegen. Das wollte ich in zukunft mal versuchen... habe es aber bisher noch nie ausgerollt...nur damit experimentiert.

[Delrabe]

@QuickAndDirty: Danke für den Hinweis.

Inzwischen habe ich allerdings entschieden, ganz auf Windows-Dienste zu verzichten. Die Update-Kontrolle wird von einer unsichtbare Kontroll-App erledigt werden, die im Hintergrund arbeitet. Das Programm wir über ein Monitor-Programm gesteuert werden, wobei der Anwender u.a. einstellen kann, dass sich die Kontroll-App. nach dem Ende einer Überprüfung selbst beendet. Damit können überflüssige Ressourcen vermieden werden. Der Anwender muss lediglich sicherstellen, dass die Kontroll-App im Autostart oder im Task Scheduler eingetragen ist, wobei es am besten ist, wenn der Update-Monitor die entsprechenden Einstellungen vornehmen kann. Dies muss ich allerdings erst noch ausknobeln.

Der Anwender wird die Update-Kontrolle über ein InnoSetup installieren müssen und dort sollten auch die benötigte Rechte abgehandelt werden.