Ich will vom Administrator-Account auf die Registry eines Users-Accounts zugreifen und Werte verändern.

HANDLE token;
BOOL a;
Long c;
a = LogonUser("work", ".", "test", LOGON32_LOGON_INTERACTIVE,LOGON32_PROVIDER_DEFAULT, &token); // a=1, d.h. das funktioniert (a=0 bedeutet Fehler!)!
a = ImpersonateLoggedOnUser(token);
...
HKEY hKey;
c = RegOpenCurrentUser(KEY_ALL_ACCESS, &hKey); // c=0, d.h. das funktioniert NICHT!

...
RegCreateKeyEx(HKEY_USERS,"work\\Software\\TEST",0,0,REG_OPTION_NON_VOLATILE,KEY_ALL_ACCESS,NULL,&hKey,0);
...
RegCloseKey(hKey);
CloseHandle(token);

Offensichtlich logt er sich noch als User work ein, da a=1 ist. Das Problem scheint bei RegOpenCurrentUser zu legen, da c=0 (c=0 bedeutet Fehler!) ist.

Was habe ich nicht bedacht? Was mache ich falsch? Kann jemand helfen?

If the function succeeds, the return value is ERROR_SUCCESS.

Und das ist in WinError.h wie folgt definiert:

#define ERROR_SUCCESS                    0L

Jedenfalls funktioniert es nicht. Es wird kein RegistryKey für den User work geschrieben.

Ich glaube hiermit stimmt was nicht: HKEY_USERS,"work\\Software\\TEST"

Hmmm, wenn der das gar nicht unter dem Namen work öffnet, dann findet er natürlich auch nicht den richtigen Platz zum Schreiben.

Betriebssystem?

Registry = Windoof

flenders schrieb:

Existiert der Pfad in der Registry bereits? Oder gibt es das work-Verzeichnis noch gar nicht.

Genau das ist wohl die Frage. Der Pfad wäre, wenn man in der Registry die Struktur für User work lädt genau so vorhanden. Wenn ich das mache, dann schreibt er diesen Schlüssel tatsächlich.

Wahrscheinlich bindet er dieses "work" nicht richtig in den Pfad ein.

Genau das ist wohl die Frage. Der Pfad wäre, wenn man in der Registry die Struktur für User work lädt genau so vorhanden. Wenn ich das mache, dann schreibt er diesen Schlüssel tatsächlich.

Du kannst ja mal mit den Enum-Funktionen nachschauen, was da ist. Bei mir gibt es aber dort in regedit keinen Schlüssel mit meinem Windows-Usernamen

BigNeal schrieb:

Betriebssystem?

Registry = Windoof

Windoof = Windows NT SPx
Windoof = Windows 2000 SPx
Windoof = Windows XP Professional SPx
Windoof = Windows XP Home SPx
Windoof = Windows 2003 Server SPx

Lass das "work" mal weg. Du gaukelst Windows doch schon vor, dass du der Benutzer "work" bist.

Ich habe nun mal die Existens des Schlüssels "HKEY_USERS\\work" geprüft. Wie erwartet findet er diesen nicht (Es sei denn ich lade in RegEdit die Struktur zuvor unter dem Namen work).

Wenn er sich tatsächlich richtig einloggt, unter welchem Registry-Schlüssel legt er dann den Schlüssel für den User (work) ab?

Wenn ich einen Schlüssel bei Current User zufüge macht er das auf dem Account auf dem ich "normal" eingeloggt bin.

Wenn er sich tatsächlich richtig einloggt, unter welchem Registry-Schlüssel legt er dann den Schlüssel für den User (work) ab?

LunaGirl schrieb:

Wenn ich einen Schlüssel bei Current User zufüge macht er das auf dem Account auf dem ich "normal" eingeloggt bin.

Kannst Du Dich mal entscheiden?

Wenn der User "work" sich einloggt und etwas in die Registry schreibt, geht das in HKEY_CURRENT_USER.

Wenn Du in HKEY_USERS schreiben willst, mußt Du erst die GUID für den USER herausfinden und könntest(!) dann in HKEY_USER\{GUID_DES_USERS} schreiben. Dann ist aber das ganze "Impersonate as User" überflüssig...

RegOpenUserClassesRoot

Wenn ih HKEY_CURRENT_USER den Schlüssel schreibe, so schreibt er diesen nicht in die Registry des andern Account. Womöglich hat er nicht verstanden, dass er sich als work einloggen soll und dessen Registry verwenden soll. Allerdings bekome ich beim einloggen auch keine Fehler - funktioniert anscheinend perfekt bis auf die Tatsache, dass er den Eintrag nicht macht.

Auch das mit der anderen USERID hat nichts gebracht. Bin in den anderen Account, habe den Schlüssel kopiert und eingesetzt. Ergebnis 0.

HKEY hKey;
HANDLE token;

if (!LogonUser("work", ".", "test", LOGON32_LOGON_INTERACTIVE,LOGON32_PROVIDER_DEFAULT, &token) || !ImpersonateLoggedOnUser(token))
{
   int err = GetLastError();
...
}
if (!RegOpenCurrentUser(KEY_ALL_ACCESS, &hKey)) \\
{
   int err = GetLastError();
...
}

RegCreateKeyEx(HKEY_USERS,">?????<Software\\TEST",0,0,REG_OPTION_NON_VOLATILE,KEY_ALL_ACCESS,NULL,&hKey,0);

RegCloseKey(hKey);
CloseHandle(token);

if (!RegOpenCurrentUser(KEY_ALL_ACCESS, &hKey)) \\

Das seh ich ja jetzt erst: ist "work" ein Admin?

Wenn nicht ist es kein Wunder, das KEY_ALL_ACCESS nicht funktioniert... Du weißt, das KEY_ALL_ACCESS auch fehlschlägt, wenn nur eins der geforderten Rechte fehlen, oder?

Nimm KEY_WRITE oder KEY_READ, aber niemals KEY_ALL_ACCESS!

Du kannst versuchen mit RegLoadKey die NTUSER.DAT des betreffenden Users in die Registry zu laden ...

In der Tat habe ich dies ganz zu Anfang versucht, mit geringem Erfolg. Daher versuchte ich eine andere Möglichkeit zu finden das Problem zu lösen. Nach Deinem Tip bin ich wieder auf RegLoadKey umgeschwenkt, auch weil mir dies eigentlich am logischten und einfachsten erscheint.

RegLoadKey funktioniert aber nicht und liefert keinen Fehlercode: 1314.
MSDN: 1314 A required privilege is not held by the client.

Wieso denn das? Ich bin in einem Account der über Adminisratorechte verfügt. Im übrigen funktioniert dies auch nicht im Admin Account selbst.

RegLoadKey(HKEY_USERS, "work", "c:\\Dokumente und Einstellungen\work\\ntuser.dat");

RegCreateKeyEx(HKEY_USERS,"work\\Software\\TEST",0,0,REG_OPTION_NON_VOLATILE,KEY_ALL_ACCESS,NULL,&hKey,0);

MSDN schrieb:

Du weißt, das KEY_ALL_ACCESS auch fehlschlägt, wenn nur eins der geforderten Rechte fehlen

Funktioniert auch mit KEY_WRITE bzw. KEY_READ nicht.

HANDLE TokenHandle = 0;
TOKEN_PRIVILEGES TP;
DWORD Regsize;
LUID RestoreLuid;
LUID BackupLuid;
int i =0;

i = OpenProcessToken( GetCurrentProcess(), TOKEN_ADJUST_PRIVILEGES | TOKEN_QUERY, &TokenHandle );

i = LookupPrivilegeValue( NULL, SE_RESTORE_NAME, &RestoreLuid );

TP.PrivilegeCount = 1;
TP.Privileges[0].Luid = RestoreLuid;
TP.Privileges[0].Attributes = SE_PRIVILEGE_ENABLED;

i = AdjustTokenPrivileges( TokenHandle, FALSE, &TP, sizeof(TP), NULL, NULL );

i = RegLoadKey(HKEY_USERS, "xxx", "c:\\Dokumente und Einstellungen\\xxx\\ntuser.dat");

Nachdem ich den Fehler 1314 bekommen habe, habe ich mich in der MSDN (und in diesem Forum) über diese Privileges Geschichte informiert. Schließlich hatte ich auch etwas gebastelt - sah sehr schlimm aus! Die herausragende Eigenschaft meines Codes war wohl eher, dass mehr Fehler produziert wurden als ich Zeilen im Code hatte.

Ich habe zwar noch nicht wirklich verstanden was Du da gemacht hast, aber ich sehe mir das jetzt mal etwas genauer an.

Ich danke allen für die Hilfe!