Zugriff auf Registry eines eingeschränkten Benutzerkontos mit Adminrechten

[amigage]

Hallo liebe Delphi-Gemeinde,

ich habe das Problem, dass ich einen SQL-Dienst stoppen und dann wieder starten möchte.
Dies ist soweit kein Problem.

Problematisch wird es, wenn ich ein eingeschränkter Nutzer bin, die demzufolge Software als Nutzer mit Adminrechten starten muss. Denn dann kann ich zwar auch den Dienst starten und stoppen. Wenn mein Programm aber gleichzeitig die Registry auslesen muss (HKEY_CURRENT_USER), erhält es die Werte der Admin-Registry und nicht des eingeschränkten Nutzers.

Wie kann man das technisch umgehen, dass man trotz angeforderter Adminrechte auf die richtige Registry zugreift? Geht das überhaupt?

amigage

[himitsu]

Vermutlich über RegOpenCurrentUser, oder den Rootpfad des entsprechenden Users selber suchen.

Das erstellte Key-Handle (HKEY) kann man dann notfalls ein ein TRegistry übergeben und dort weiter nutzen.

[p80286]

Zitat:

Zitat von amigage (Beitrag 1141624)

Problematisch wird es, wenn ich ein eingeschränkter Nutzer bin, die demzufolge Software als Nutzer mit Adminrechten starten muss. Denn dann kann ich zwar auch den Dienst starten und stoppen. Wenn mein Programm aber gleichzeitig die Registry auslesen muss (HKEY_CURRENT_USER), erhält es die Werte der Admin-Registry und nicht des eingeschränkten Nutzers.

Wie sieht dies denn konkret aus?
Du bist als User1 angemeldet und benutzt runas um als Admin ein weiteres Programm zu starten?

Gruß
K-H

[amigage]

Vielen lieben Dank Euch beiden, für die schnelle Reaktion.

Zitat:

Zitat von p80286 (Beitrag 1141630)

Du bist als User1 angemeldet und benutzt runas um als Admin ein weiteres Programm zu starten?

Genauso siehts aus. Ich habe durch den Hinweis auf RegOpenCurrentUser mal meine Funktion versucht umzubasteln, aber irgendwie bekomme ich bei User1 und runas Admin immer noch die Werte des Admin. Wo liegt bei mir der Fehler?

Delphi-Quellcode:

function ReadRegistryValue(MyHKey : Byte; RegKey : String;  RegValue : String) : String; overload;
var
  Reg : TRegistry;
  RegOpenCurrentUser: TRegOpenCurrentUser;
  hkResult: HKEY;
begin
  Result := '';
  Reg:=TRegistry.Create;
  try

    if MyHKey = 1 then
    begin
      RegOpenCurrentUser := GetProcAddress(GetModuleHandle('ADVAPI32.DLL'), 'RegOpenCurrentUser');
      if Assigned(RegOpenCurrentUser) then
        if RegOpenCurrentUser(KEY_READ, @hkResult) <> ERROR_SUCCESS then
        begin
          showmessage('geht nicht!');
          exit;
        end;
    end;

    Case MyHKey of
      1:  Reg.RootKey:= hkResult; //HKEY_CURRENT_USER;
      2:  Reg.RootKey:= HKEY_LOCAL_MACHINE;
      3:  Reg.RootKey:= HKEY_CLASSES_ROOT;
    end;

    Reg.Access := KEY_READ;
    if Reg.OpenKey(RegKey, False) then
      If Reg.ValueExists(RegValue) then
      begin
        try
          Result := Reg.ReadString(RegValue);
        except
          Result := '';
        end;
      end;

  finally
    Reg.CloseKey;
    Reg.Free;
  end;
end;

[amigage]

Hat sich erledigt. Es funktioniert!

Es lag daran, dass ich den Admin und den eingeschränkten Nutzer gleichzeitig offen hatte. Jetzt, nachdem ich neu gebootet habe und nur den eingeschränkten Nutzer geöffnet habe, arbeitet die Software so, wie sie soll.

[himitsu]

Zitat:

Zitat von amigage (Beitrag 1141711)

Jetzt, nachdem ich neu gebootet habe und nur den eingeschränkten Nutzer geöffnet habe, arbeitet die Software so, wie sie soll.

Ist aber auch eine böse Falle, vorallem wenn es bei einem Terminl-Server genauso ist.

[amigage]

Mist, leider zu früh gefreut! Da mein Beispielprogramm bei meinem letzten Test nicht die Werte des Admin angezeigt hat, war ich der Meinung, jetzt greift er richtig zu.

Falsch gedacht: denn nachdem ich jetzt nach real existierenden Registryeinträgen des eingeschränkten Nutzers mit Adminrechten gesucht habe, erhalte ich nicht die Werte. Der Grund: Windows legt einen temporären Nutzer an (erkennbar an C:\Users\TEMP\) und greift damit wahrscheinlich auf eine nicht exisierende Registry zu.

Verlasse ich den eingeschränkten NUtzer und starte ihn neu, ist der TEMP-User wieder weg. Bis ich wieder versuche, mit meinem Programm und Adminrechten auf die Registry zuzugreifen.

Muss ich noch irgendetwas beachten? Ich bin schon fast am Verzeifeln und würde mich über jeden nützlichen Hinweis freuen.

@himitsu:

Zitat:

oder den Rootpfad des entsprechenden Users selber suchen.

Wie kann ich erfahren, welcher Pfad für den eingeschränkten User verantwortlich ist?

Besten Dank,
amigage

[Luckie]

Lade den gewünschten benutzerspezifischen Registry Hive manuell selber.

[amigage]

Hallo Luckie,

okay, ich habe es jetzt mit Deiner Funktion GetAccountSid versucht. Problem ist nur, ich brauche hier den Benutzernamen.

Aber meine Funktion gibt mir immer nur den aktuellen Windows-Nutzernamen. In dem Fall den Admin-Nutzernamen.

Delphi-Quellcode:

function GetCurrentUserName: string;
const
  cnMaxUserNameLen = 254;
var
  sUserName:     string;
  dwUserNameLen: DWORD;
begin
  dwUserNameLen := cnMaxUserNameLen - 1;
  SetLength(sUserName, cnMaxUserNameLen);
  GetUserName(PChar(sUserName), dwUserNameLen);
  SetLength(sUserName, dwUserNameLen);
  Result := trim(sUserName);
end;

Wie erhalte ich den Nutzernamen des tatsächlich geöffneten Nutzers ohne Adminrechte?

[amigage]

Ich habe noch ein wenig im Netz recherchiert und bin auf die Mtx Unit gestoßen (MS Transaction Server Interface Unit).
Hier gibt es unter ISecurityProperty die Funktion GetDirectCallerSID() mit der ich - soweit wie ich das verstanden habe - die SID des originalen Prozesses auslesen kann.

Die Hilfe von Delphi ist nicht weiter aussagekräftig und hilft mir leider auch nicht weiter.
Im Netz habe ich einen Codeschnipsel gefunden, der aber auch nicht wirklich weiterhilft, da bei

Delphi-Quellcode:

If Assigned(ObjectContext) then

der Compiler den Fehler "Inkompatible Typen" ausgibt.
http://www.tek-tips.com/viewthread.cfm?qid=33539

Kann mir vielleicht einer einen Tipp geben, wie ich diese Funktion GetDirectCallerSID() aufzurufen habe?

Vielen Dank!
amigage

[Luckie]

GetUserName gibt dir immer den Benutzer zurück in dessen Kontext der Prozess7Thread läuft von dem die Funktion aufgerufen wird. Und was ist für dich der "tatsächlich geöffnete Benutzer"? an einem System können mehrere Benutzer angemeldet sein. Interaktiv nur einer aber remote beliebig viele. Und tatsächlich sind sogar immer mehrere Bneutzer angemeldet. System zum Beispiel unter dem die meisten Dienste laufen.

[amigage]

Hallo Luckie,

Zitat:

Und was ist für dich der "tatsächlich geöffnete Benutzer"?

Ich meine den Benutzer, der in dem Moment verwendet wird. Meine Software braucht aber wegen einer anderen Funktion Adminrechte, muss aber dann auch auf die Registry des momentan sichtbar geöffneten Nutzers zugreifen. Mit RegOpenCurrentUser bekomme ich ja dann nur die Registrywerte eines temporären Nutzers.

Ich habe halt versucht, mit GetUserName den Benutzernamen herauszufinden, um Deine Funktion GetAccountSid verwenden zu können und somit den entsprechenden HKEY_USERS Pfad zu ermitteln.

Oder wie meintest Du die Aussage?

Zitat:

Lade den gewünschten benutzerspezifischen Registry Hive manuell selber.

[Luckie]

Und welcher Benutzer soll das sein?

Mir kommt dein Programmdesign immer verkorkster vor. Warum muss der Administrator Einstellungen vom Benutzer ändern? Und wie sieht es aus, wenn es mehrere Benutzer gibt, die das Programm benutzen? Unter HKLM kommen nur globale Einstellungen, die von den Benutzern nur gelesen werden sollen. Unter HKCU kommen dann die individuellen Einstellungen der Benutzer.

[amigage]

Vielleicht erkläre ich es ein wenig besser.

Das Programm muss einen Windows Dienst stoppen. Dies kann es nur mit Adminrechten. Dann muss die Software Daten aus der Registry des Nutzers lesen, um auf bestimmte Dateien zugreifen und austauschen zu können. Diese Information findet sich nur in der Registry des angemeldeten Nutzers, also dem, der die Software von Hand gestartet hat. Dann soll der Dienst wieder gestartet werden.

Als Problem gestaltet es sich, wenn der Nutzer ein eingeschränkter Nutzer ist und die Adminrechte vom Adminkonto angefordert werden.

Wie würdest Du es machen?

[Bummi]

Unter wessen Account läuft der Dienst, ist es ein Dienst den Du im Source hast, bzw. den Du anpassen kannst?

[blackfin]

Und wenn du einfach den derzeitigen Benutzernamen vor dem Starten des Admin-Programms einfach irgendwo zwischenzpeicherst, wo ihn das Admin-Programm auch wieder auslesen kann? Irgendwo in einer Datei in CSIDL_COMMON_APPDATA oder Ähnlichem?

[himitsu]

Irgendwie ist es doch möglich rauszubekommen von welchem Programm ein Programm gestartet wurde.
> schauen welches programm das war und in wessen Benutzerkontext dieses läuft

Vielleicht bekommt man auch einfach raus, zu welchem Benutzer der Desktop gehört, auf welchem das Programm grade sichtbar ist.

Vorallem in Bezug auf Terminal-Server gibt es ja nicht den einen aktiven Benutzer
und ein Service läuft standardmäßig im Service-Account und nicht im auswechselbaren Benutzeraccount usw.

Alternativ gibt es noch einige Varianten
- zwei Programme
- nur einen Arbeitsthread mit Adminrechten impersonaten (oder irgendwie so),

[MGC]

mal ganz abgesehen davon, wenn ich mir das mal bei uns an der Arbeit vorstelle. Ich arbeite an meinem Rechner in Kassel und jetzt öffnet sich eine Anforderung für Adminrechte, die ich natürlich nicht habe. Daraufhin rufe ich in Wiesbaden an, dass ich mal kur nebenher eine Remote-Desktop-Unterstützung benötige. (Bitte lieber Admin..äh, welcher von denen eigentlich?) tippe mal Dein PW ein, danke.

Wie oft am Tag kann das denn so vorkommen?

[himitsu]

Wenn das "öfters" vorkommt, dann muß eben zusätzlich ein Service laufen, welcher (nur) diese Einstellungen vornimmt (über den System-Accoount).

[MGC]

ja, das könnte ich mir eher vorstellen als die Anforderung von Admin-Rechten für das eingeschränkte Konto.

[amigage]

Zitat:

Unter wessen Account läuft der Dienst, ist es ein Dienst den Du im Source hast, bzw. den Du anpassen kannst?

@Bummi: der Dienst meldet sich als Netzerkdienst an und ich habe den Dienst nicht in der Source.

Zitat:

Und wenn du einfach den derzeitigen Benutzernamen vor dem Starten des Admin-Programms einfach irgendwo zwischenzpeicherst, wo ihn das Admin-Programm auch wieder auslesen kann? Irgendwo in einer Datei in CSIDL_COMMON_APPDATA oder Ähnlichem?

@blackfin: Dachte ich mir auch schon, aber der Anwender kann ja theoretisch das Programm gleich als Admin ausführen. Da kann ich den Benutzernamen leider nicht zwischenspeichern.

Zitat:

Vielleicht bekommt man auch einfach raus, zu welchem Benutzer der Desktop gehört, auf welchem das Programm grade sichtbar ist.

@himitsu: Bleibt nur die Frage: wie?

Ich dachte ja, dass man mit der von mir genannten Funktion GetCallerSID() genau die SID des Nutzers erhält, der die Software aufgerufen hat. Ich weiß nur nicht, wie ich diese anzuwenden habe.

@himitsu + MGC: Ich gehe eher von dem lokalen Einsatz auf einem Standalone-Rechner aus, bei dem der Anwender aus Gründen der Sicherheit beim Web-Surfen eher auf einen eingeschränkten Benutzer zurückgreift.

[amigage]

Hallo,

leider habe ich bisher keine Lösung für mein Problem finden können.

Den Zugriff auf die Registry kann man ja wirklich noch umgehen, indem man "unprofessioneller Weise" den eingeschränkten Nutzernamen abspeichert und dann als Admin ausliest. Somit erhält man den richtigen SID für den HKEY_USERS Registryzweig.

Problematischer ist es da schon, wenn man auf Standardpfade zugreifen will:

Delphi-Quellcode:

  try
    SetLength(lPath, MAX_PATH);
    if SHGetSpecialFolderPath(0, @lPath[1], CSIDL_APPDATA, False) then
    begin
      SetLength(lPath, pos(#0, lPath) - 1);
      Result := lpath;
    end;
  except
    // ...
  end;

Hier erhält man wirklich nur die Pfade des Adminkontos statt des eingeschränkten Kontos! Oder kann man dies irgendwie korrigieren?

[MGC]

Erstmal noch frohes neues Jahr!

Wenn ich diesen Thread noch richtig im Kopf habe, startest Du Dein Programm von einem eingeschränkten Nutzerkonto aus und startest dann für bestimmte Vorgänge das Admin-Konto.
Wie wäre es demnach, wenn Du die Pfade ausliest bevor Du in den Adminmodus wechselst?

[amigage]

Hallo,

Dir auch ein frohes neues Jahr.

Zitat:

Wie wäre es demnach, wenn Du die Pfade ausliest bevor Du in den Adminmodus wechselst?

Das wäre kein Problem, wenn der Nutzer die Software nicht schon von selbst als Admin startet bzw. es direkt in den Eigenschaften der exe fest hinterlegt.

Ich habe zwar für mein Problem eine andere Lösung gefunden, so dass ich nicht mehr in den Admin-Modus muss, aber interessieren würde es mich schon, wie man das hinbekommt, ohne vorher Daten über den Windows-Benutzernamen und Standardpfade in einer Datei abzulegen.

[Luckie]

Zitat:

The correct way to load and manipulate a specific user's Registry hive is to having your calling thread impersonate that user

http://stackoverflow.com/questions/8...ve-with-delphi

Zusammen mit http://michael-puff.de/Programmierun...ersonate.shtml sollte das Problem lösbar sein.

[Luckie]

Delphi-Quellcode:

{-----------------------------------------------------------------------------
 Project      : -
 Description  : Enhancement of TRegistry for impersonating the registry
 Author       : Michael Puff [http//michael-puff.de]
 Date         : 2012-01-05
-----------------------------------------------------------------------------}

unit RegistryEx;

interface

uses
  Windows, SysUtils, Registry;

type
  TRegistryEx = class(TRegistry)
    private
      FUser: string;
      FPassword: String;
      function Impersonate: Boolean;
    public
      destructor Destroy; override;
      procedure ImpersonateUser(UserName: string; Password: string);
  end;

implementation

{ TRegistryEx }

destructor TRegistryEx.Destroy;
begin
  if not RevertToSelf then
    Halt;  // if revert fails kill process for safty reason
  inherited;
end;

procedure TRegistryEx.ImpersonateUser(UserName: string; Password: string);
begin
  FUser := UserName;
  FPassword := Password;
  if not Impersonate then
    RaiseLastOSError;
end;

function TRegistryEx.Impersonate: Boolean;
var
  LogonType         : Integer;
  LogonProvider     : Integer;
  TokenHandle       : THandle;
begin
  LogonType := LOGON32_LOGON_INTERACTIVE;
  LogonProvider := LOGON32_PROVIDER_DEFAULT or LOGON32_PROVIDER_WINNT50;
  Result := LogonUser(PChar(FUser), nil, PChar(FPassword), LogonType, LogonProvider, TokenHandle);
  if Result then
  begin
    Result := ImpersonateLoggedOnUser(TokenHandle);
    CloseHandle(TokenHandle);
  end;
end;

end.

Delphi-Quellcode:

uses
  RegistryEx;

procedure TForm1.btn1Click(Sender: TObject);
var
  reg: TRegistryEx;
begin
  reg := TRegistryEx.Create;
  try
    reg.ImpersonateUser('user', 'pw');
    
  finally
    reg.Free;
  end;   
end;

Probier das mal. Habe es eben nur mal blind getippt, kann es leider hier nicht testen.

[amigage]

Hallo Luckie,

auch Dir ein erfolgreiches 2012!

Ich danke Dir für den Hinweis und die superschnelle Umsetzung eines Beispiel-Codes. Ich habe es jetzt auch noch nicht getestet. Nur wie ich die Sache sehe, benötige ich doch wieder den Benutzernamen des eingeschränkten Nutzers. Den weiß das Programm doch aber nicht, wenn es sofort als Admin gestartet wird.

Besser wäre es doch, wenn ich den Benutzernamen des tatsächlich geöffneten Windows-Benutzers erhalte, obwohl ich die Software als Admin starte. Sonst habe ich nur wieder den Admin-Nutzernamen. Oder verstehe ich das jetzt falsch?

[Luckie]

Natürlich brauchst du Name und Passwort des Benutzers auf dessen Registry Hive zu zugreifen willst. Sonst könnte ja jeder als Administrator agieren. Und was ist für dich der "tatsächlich geöffneten Windows-Benutzer"? An einem Windows System können viele Benutzer angemeldet sein und arbeiten. Woher soll das Programm wissen, welcher Benutzer gemeint ist? Wenn ein Benutzer ein Programm unter anderen Konto startet, dann ist das für das gestartete Programm so, als ob der Nutzer mit dem andren Konto es gestartet hätte.

[amigage]

Code:

Wenn ein Benutzer ein Programm unter anderen Konto startet, dann ist das für das gestartete Programm so, als ob der Nutzer mit dem andren Konto es gestartet hätte.

Das wollte ich doch nur wissen :) Ich dachte, es gäbe eine Möglichkeit, dies auszulesen. So in der Art: das Adminkonto wurde von einem eingeschränkten Benutzerkonto, wie hieß das?

Dem ist also nicht so! Somit steht also fest, dass Programme, die unter einem eingeschränkten Windows-Nutzer ohne Adminrechte als "Administrator ausgeführt" werden, nie richtig funkionieren werden, wenn sie eigentlich auf die Nutzer-Registry zugreifen müssen, oder Nutzzer-Standardpfade %UserProfiles%, %Documents% bzw. den Desktop CSIDL_DESKTOPDIRECTORY auslesen müssen. Denn dann erhält man immer die Daten des Adminkontos.

Ist das korrekt?

[DeddyH]

Starte doch einfach mal cmd.exe als Administrator und schau, was SET so ausgibt.

[Luckie]

Man könnte höchstens den Benutzer des Elternsprozesses ermitteln. Aber dann fehlt dir ja immer noch das Passwort.

[MGC]

Es gibt schon einen Grund warum das so ist und der heißt Malware. Aber um Dien Problem einigermaßen zu umschiffen, kannst Du Luckies Vorschlag nutzen oder eine StartUp-Schicht einfügen, welche die benötigten Daten sammelt, wozu jedoch nicht das Admin-Passowrt gehört. Daher wurdest Du gleich zu Beginn dieses Threads auch immer wieder gefragt, ob Du den Admin nerven möchtest, wenn er immer wieder sein Passwort eingeben muss.

An dieser Stelle solltest Du jedoch auch bedenken, dass dieses Vorgehen ein erhöhtes Sicherheitsrisiko bedeutet. Immerhin hast Du extra ein eingeschränktes User-Konto für den Internet-Zugriff erstellt und möchtest dieses nun die ganze Zeit über wieder umgehen.

Wenn Du Dir nun einen Trojaner eingehandelt hast, der einen Keylogger nachinstalliert, dann hast Du auf diese Weise möglicherweise soeben Deinen Rechner kapern lassen.

Denk mal drüber nach. :vernupft:

[Dezipaitor]

Ich habe gerade alles durchgelesen und verstehe immernoch nichts.

Krze Fragen:

1. Windows XP oder Vista oder 7?
2. Es läuft irgendein SQL Server als Dienst. Den willst du starten und stoppen als Admin?
3. Du willst auf die Registry des Benutzers zugreifen. Dort stehen irgendwelche Einstellungen drin?

Ich folgere:
Du hast ein Programm, das kann ohne Adminrechte irgend etwas machen (z.B. Registry des Users benutzen). Aber manchmal willst du darin auch den SQL Server steuern (starten/stoppen). Dafür brauchst du Adminrechte.
Deshalb muss der Benutzer derzeit schon von Anfang an dein Programm als Admin starten. Aber dann kannst du die Benutzereinstellungen des normalen Benutzers nicht nutzen, sondern nur vom Admin. Alles korrekt?

Jetzt kommt Frage 1 ins Spiel: Ich verstehe nicht, wie keiner danach fragen konnte?
Unter XP ist der Administrator ein eigenes Benutzerkonto mit eigener Registry. Ab Vista ist ein Administrator erst einmal ein normaler User und wird durch eine Abfrage an den Nutzer (UAC) für einen Prozess zum Admin. Aber es gibt auch Benutzer, die keine Admins sind und bei denen wieder ein echter Admin sich anmelden muss, der dann natürlich wie in XP mit eigener Registry ankommt.

Für Vista ist die Lösung einfach. Baue den Code für die SQL Serversteuerung aus der Anwendung aus und setze sie in eine COM-DLL (nennt sich COM Elevation Moniker). Mit Windows kann diese DLL als Admin ausgeführt werden, ohne dass dein Prozess dazu Adminrechte braucht.
In XP geht es leider nicht. Stattdessen musst du einen neuen Prozess mit Adminrechten (z.B. ShellExecute und Verb = runas) starten, der eben den SQL Server stoppt/startet. Du kannst z.B. deiner Anwendung Kommandozeilenparameter verpassen, um dies zu machen und dann eben die eigene Anwendung kurzzeitig nochmal sicht selbst starten lassen (über Verb = runas).
Über den Prozessrückgabewert kannst du Fehler prüfen oder auch eine Kommunikation über Pipes, Events und MemoryMapped Files herstellen. Die Sache ist also einfach: Dein Prozess läuft ohne Admin und startet dann kurzzeitig einen weiteren Prozess mit Adminrechten, der die SQL Serversteuerung übernimmt: Teile und herrsche

[amigage]

Zitat:

Zitat von Dezipaitor (Beitrag 1144586)

Ich habe gerade alles durchgelesen und verstehe immernoch nichts.

Doch, Du hast alles richtig verstanden.

Zitat:

Zitat von Dezipaitor (Beitrag 1144586)

1. Windows XP oder Vista oder 7?
2. Es läuft irgendein SQL Server als Dienst. Den willst du starten und stoppen als Admin?
3. Du willst auf die Registry des Benutzers zugreifen. Dort stehen irgendwelche Einstellungen drin?

Genauso sieht es aus :)

ich danke Dir auch für die ausführliche Erläuterung zur Problemlösung, die ich bei Gelegenheit einmal ausprobieren werde. Wie gesagt, derzeit habe ich eine andere Lösung gefunden. Die Lösung mit runas als separates Programm kam mir auch in den Sinn.

Zitat:

In XP geht es leider nicht.

Das ist nicht so tragisch, da es dort keine UAC gibt.

[Dezipaitor]

Sry, hab ich wohl überlesen. Ich sehe nicht, dass du eine Lösung gepostet hättest.