Zugriff auf "Eigene Dateien" / "Registry" vom Dienst aus

[greenmile]

Hallo,

ich benötige von meinem Dienst aus Zugriff auf die jeweils aktuelle CURRENT_USER Registry bzw auf den Pfad "Eigene Dateien". Das Problem liegt auf der Hand: Ein Dienst sieht eigentlich nur sich selbst, also linkt CURRENT_USER nur auf die Registry des Dienstes. Jetzt war meine Idee, dass ich ja die SID vom aktuell angemeldeten User auslesen und diese für HKEY_USERS\S-1238 usw verwenden kann. Leider finde ich hierüber keinen Source, hat jemand eine Idee? Den Usernamen des jeweils aktuellen Benutzers kann ich korrekt auslesen (dank http://www.delphipraxis.net/615483-post1.html), aber wie lese ich die SID aus? Und funkioniert es korrekt mit HKEY_USERS\{SID}?

Paul

[Assarbad]

Zitat von greenmile:

[...] aber wie lese ich die SID aus? Und funkioniert es korrekt mit HKEY_USERS\{SID}?

Mit LookupAccountSid . Ob die vom Service aus sichtbar sind, weiß ich nicht ad-hoc, aber sollten eigentlich. Funktioniert aber nur wenn der entsprechende Hive geladen ist (RegLoadKey).

Übrigens: was ist denn deiner Meinung nach der jeweils aktuelle Benutzer?

[greenmile]

Habe gerade gesehen, dass mir die Nachricht WTS_SESSION_LOGON ja als lParam die SessionID übergibt. Die Frage ist jetzt bloss, wie ich damit weitermache. Ich benötige eine View auf die Registry vom aktuellen Benutzer, also für den, der gerade die Tastatur verwendet. Hintergrund ist, dass der Dienst Daten aus der Registry ausliest, die jeweils für den aktuellen Benutzer gelten. Loggt sich ein Benutzer ein, muss der Dienst aus HKCU Daten auslesen und diese auswerten. Ist übrigens kein Virus o.ä.

Hast Du eine Idee?

[Assarbad]

Zitat von greenmile:

Habe gerade gesehen, dass mir die Nachricht WTS_SESSION_LOGON ja als lParam die SessionID übergibt.

Ich bin verwirrt. Wie kommst du darauf, daß dir das weiterhilft?

Zitat von greenmile:

Ich benötige eine View auf die Registry vom aktuellen Benutzer, also für den, der gerade die Tastatur verwendet.

Kannst du nicht wirklich herausbekommen. Wenn man es je nach System eingrenzt, gibt es weitere Anhaltspunkte, aber ein sicheres System ist mir noch nicht untergekommen.

Wer das behauptet blendet nämlich aus, daß es sich bei der NT-Plattform um Mehrbenutzersysteme handelt.

Zitat von greenmile:

Hintergrund ist, dass der Dienst Daten aus der Registry ausliest, die jeweils für den aktuellen Benutzer gelten. Loggt sich ein Benutzer ein, muss der Dienst aus HKCU Daten auslesen und diese auswerten.

Ein Programm welches im Kontext des entsprechenden Benutzers läuft könnte deinem Dienst bescheidgeben und die entsprechenden Daten sogar gleich mitliefern. Wäre allemale sauberer als das was sich bisher hier abzeichnet.

[Dezipaitor]

Funktionsaufrufe:

WTSGetActiveConsoleSession dann WTSQueryUserToken

SHGetFolderPath mit Token
und
KORREKTUR
RegOpenUserClassesRoot
bzw.
ImpersonateLoggedOnUser mit token, dann
RegOpenCurrentUser

[Assarbad]

Zitat von Dezipaitor:

RegOpenCurrentUser bzw.
RegOpenUserClassesRoot

Funktionieren die ohne Impersonation?

Auf WTSGetActiveConsoleSession bin ich nicht gekommen. Aber stimmt, wäre ja die Konsole wenn es derjenige vor der Tastatur sein soll.

[Dezipaitor]

So genau habe ich garnicht geschaut

Das erste RegXXX geht direkt mit einem Token, das zweite mit ImpersonateLoggedOnUser.

[greenmile]

Super, ich bin fast am Ziel

1. WTSQueryUserToken(SessionID, hUserToken);
2. ImpersonateLoggedOnUser(hUserToken);

Funktioniert beides, also keine Fehlermeldung. Aber: Jetzt hänge ich am 3ten Punkt.


implementation

function RegOpenCurrentUser(samDesired: REGSAM; phkResult: PHKEY): LongInt; external 'Advapi32.dll' name 'RegOpenCurrentUser';

...
var phkRoot: HKEY;
...
RegOpenCurrentUser(KEY_READ, @phkRoot);


Die Funktion gibt mir immer den Fehlercode 998 zurück (ERROR_NOACCESS?). Das verstehe ich nicht, eigentlich müsste ich doch Zugriff haben?

[Assarbad]

Zitat von greenmile:

Die Funktion gibt mir immer den Fehlercode 998 zurück (ERROR_NOACCESS?). Das verstehe ich nicht, eigentlich müsste ich doch Zugriff haben?

Mangels Testumgebung kann ich das hier nicht nachvollziehen, aber ERROR_NOACCESS klingt ähnlich wie ERROR_ACCESS_DENIED (5), es klingt aber auch an, daß der ACL vielleicht keinen passenden ACE enthält. Haste versucht den ACL des Schlüssels vor Zugriff mal anzupassen? Wäre ja auch mal interessant ob du wirklich im korrekten Kontext läufst. Versuch doch mal a.) die ACEs des obersten Schlüssels auszulesen und b.) eine Ereignis ins Log zu schreiben (da ist dann zu sehen welcher Benutzerkontext es war).

[greenmile]

War ein Fehler meinerseits, die Funktion war nicht aus der DLL geladen; jetzt funktioniert es, VIELEN DANK!

Für die Nachwelt:

1. WTS_SESSION_LOGON,WTS_CONSOLE_CONNECT und WTS_REMOTE_CONNECT im Dienst abfangen, lParam enthält die SessionID
2. WTSQueryUserToken(SessionID, hUserToken); // SessionID in hUserToken
3. ImpersonateLoggedOnUser(hUserToken); // Als User anmelden
4. phkRoot: HKEY;
RegOpenCurrentUser(KEY_READ, @phkRoot); // Registry mappen

Anschließend kann der Dienst so auf die CURRENT_USER zugreifen:

With TRegistry.Create do begin
RootKey := phkRoot; // Von RegOpenCurrentUser anstelle von HKEY_CURRENT_USER
...
End;

Um die Pfade auszulesen (Eigene Dateien), anstelle von Punkt 4 einfach "CreateEnvironmentBlock" aufrufen.

5. RevertToSelf; // Nicht vergessen: Ursprünglicher User, das Gegenteil von ImpersonateLoggedOnUser