![]() |
[gelöst]Impersonate in TService
Hi zusammen...
Ich verwende seit ewigen Zeiten das Impersonate von Luckies webseite. Klappt auch immer ganz prima. Nur leider scheinen die Gegebenheiten innerhalb eines Services etwas anders. Hier ist mein Code:
Delphi-Quellcode:
im Log dann Folgendes:
function Impersonate(const aUser, aPass: string): Boolean;
var LogonType : Integer; LogonProvider : Integer; strUser : String; strDomain : String; strPassword : String; Token: THandle; begin LogonType := LOGON32_LOGON_INTERACTIVE; LogonProvider := LOGON32_PROVIDER_DEFAULT; strUser := aUser; strDomain := ''; strPassword := aPass; Result := LogonUser(PChar(strUser), nil, PChar(strPassword), LogonType, LogonProvider, Token); generateLog('muh1'); if Result then begin generateLog('muh2'); Result := ImpersonateLoggedOnUser(Token); // hier bleibts hängen generateLog('muh3'); end; end; // Der Aufruf: generateLog('vorher-'+GetUsername); Impersonate('User', 'Pass'); generateLog('nachher-'+GetUsername);
Code:
Und dann bleibt der Prozess hängen. Gelten für den System-User andere Regeln? Gibt es nen anderen Weg?
vorher-SYSTEM
muh1 muh2 Gruß, Toni |
AW: Impersonate in TService
Zitat:
|
AW: Impersonate in TService
Was ist den unordentlich wenn man den Dienst so installiert wie er aus dem Kompiler kommt?
|
AW: Impersonate in TService
Zitat:
Soll Dir Delphi gültige Service Credentials anlegen und mit in die exe packen? Das wäre in etwa vergleichbar mit "Ein frisch assembliertes Auto braucht keine Zulassung und keinen Fahrer mit gültiger Fahrerlaubnis... Sonst wäre der Unfug doch gleich mit dabei!". LOKALES SYSTEM Konto: - hat eine NULL SID und somit keinen Zugriff auf Netzwerkressourcen (ist vermutlich auch die Ursache für dein obiges Problem) - ist eher "unsauber", da viel zu hohe lokale Berechtigungen - eher störanfällig bei neuen Windows Versionen, da MS die Berechtigungsringe um den Kernel immer weiter härtet und Berechtigungen "nach außen" verlagert. Irgendwann geht irgendwas nicht mehr (wie interaktive Dienste usw.). Dienstkonto: - hat eine SID, der Zugriff auf Netzwerkressourcen gewährt werden können - kann explizit geforderte Berechtigungen erhalten - ist aber auch nicht mehr "State of the Art" Managed Service Account: - hat eine SID, der Zugriff auf Netzwerkressourcen gewährt werden können - kann explizit geforderte Berechtigungen erhalten - Windows kümmert sich um komplexe, regelmäßig geänderte Kennwörter |
AW: Impersonate in TService
Der Kompiler hat in sofern etwas damit zu tun, dass er mir einen Button auf dem Form kompiliert hat, der den Dienst so wie er ist Installiert und startet. Oldschool. Hab ein zugegebenermaßen schon recht altes Tutorial verwendet um mich da ein zu arbeiten.
Hab mich noch den ganzen Abend versucht schlau zu lesen in Bezug auf "Managed Service Accounts". Scheint ja nu state of the Art zu sein. Doof ist nur, dass ich schon gern auch alte Betriebsysteme verwenden wollte. Entwickle selbst auf Vista und XP ist hier auch noch nicht ganz tot. Da gibts das offenbar noch nicht. Wenn es also irgendwie geht würd ich gern bei "erprobter", um nicht su sagen altmodischer, Technik bleiben. Mich wundert auch ein bisschen, dass der Code an der stelle einfach stehen bleibt. Müsste ich, wenn es sich um Rechte- oder Zugriffsprobleme handelt, nicht eine Exception oder negative Rückgabe erwarten? Toni |
AW: Impersonate in TService
Zitat:
Es ist aber auch nicht viel schlechter, wenn man sich ein ganz normales Benutzerkonto erstellt, dem man die nötigen Rechte gibt und das man als Dienstkonto verwendet. Ohne groß zu forschen... Eventuell bleibt die Ausführung stehen weil: - der Service Thread durch eine Exception hängt - oder der Dienst dem Benutzer SYSTEM auf der Konsole "Session 0" irgendwelche modalen Meldungen anzeigt (die Du dann nicht siehst) - oder die Benutzerkontensteuerung dem User SYSTEM um eine Elevation bittet |
AW: Impersonate in TService
Klingt plausibel.
Ich hab also jetzt testweise den Dienst mal unter meinem Admin-"Personen-Konto" gestartet und ein Impersonate versucht. Selbes Problem. Ausserdem hab ich diverse Konstelationen getestet, die den selben Code unter dem Selben Admin-Konto in einer Desktop-Applikation ausführt. Dort funktioniert er weiterhin wie gewohnt und es wird auch keine UAC-Meldung geworfen.
Code:
Ein von Anfang an enthaltener Try-Except-Block, der den gesammten Execute-Teil des Service-Threads umfasst und einen Log-Eintrag macht damit ich mich an eventuelle Probleme ran tasten kann, wurde bisher nie angesprungen.
vorher-Toni
muh1 muh2 muh3 nachher-Testuser revert-Toni Toni |
AW: [gelöst]Impersonate in TService
Meine weiteren Recherchen haben das Problem eingekreist und schlußendlich die Lösung zu Tage gefördert.
Für die, die zukünftig mal ähnliche Probleme haben hier die Lösung:
Delphi-Quellcode:
Damit funktioniert Luckies Funktion in Services so wie man es vom Desktop gewohnt ist.
function Impersonate(const aUser, aPass: string): Boolean;
[..] begin LogonType := LOGON32_LOGON_NETWORK; //LOGON32_LOGON_INTERACTIVE; [..] Gruß, Toni |
AW: [gelöst]Impersonate in TService
Auch wenn man dien Dienst unter dem LOCAL SYSTEM, NETZWERKDIENST usw. laufen lässt?
|
AW: [gelöst]Impersonate in TService
Ich installiere und starte den Service wie
![]() Mein Log sieht jetzt so aus:
Code:
vorher-SYSTEM
nachher-Toni revert-SYSTEM Genau was ich wollte. |
Alle Zeitangaben in WEZ +1. Es ist jetzt 00:12 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz