Lokal Adminrechte erlangen

[Hobbycoder]

Mein Programm wird in der Regel aus einem Netzlaufwerk gestartet. Für einige Client's, die über VPN angebunden sind, soll eine Funktion mit rein, das Programm lokal zu installieren, da die VPN teilweise keine große Bandbreite hat.

Ich versuche über folgende Methoden mein Programm kurz und knapp lokal auf den Rechner zu bringen.

Delphi-Quellcode:

function Impersonate(const User, PW: string): Boolean;
var
  LogonType         : Integer;
  LogonProvider     : Integer;
  TokenHandle       : THandle;
  strAdminUser      : string;
  strAdminDomain    : string;
  strAdminPassword  : string;
  i: Integer;
begin
  LogonType := LOGON32_LOGON_INTERACTIVE;
  LogonProvider := LOGON32_PROVIDER_DEFAULT;
  strAdminUser := User;
  if Pos('\', strAdminUser)=0 then
  begin
    strAdminDomain:='.';
  end else begin
    strAdminDomain := Copy(strAdminUser, 1, pos('\', strAdminUser)-1);
    strAdminUser := Copy(strAdminUser, Pos('\', strAdminUser)+1, Length(strAdminUser));
  end;
  strAdminPassword := PW;
  if strAdminDomain<>'' then
  begin
    Result := LogonUser(PChar(strAdminUser), PChar(strAdminDomain),
      PChar(strAdminPassword), LogonType, LogonProvider, TokenHandle);
  end else begin
    Result := LogonUser(PChar(strAdminUser), nil,
      PChar(strAdminPassword), LogonType, LogonProvider, TokenHandle);
  end;
  if Result then
  begin
    Result := ImpersonateLoggedOnUser(TokenHandle);
  end;
end;

function LocalInstallation(UserName, Password: string): string;
var
  Directory: string;
begin
  Result:='';
  if Impersonate(UserName, Password) then
  begin
    Directory:=getWinSpecialFolder(CSIDL_PROGRAM_FILESX86)+'MeinProgramm\';
    if ForceDirectories(Directory) then
    begin
      if CopyFile(PChar(Application.Exename), PChar(Directory+ExtractFileName(Application.ExeName)), True) then
      begin
        CreateShortcut(Directory+ExtractFileName(Application.ExeName), _DESKTOP, '',Directory,'','', 'MeinProgramm.lnk');
        CreateShortcut(Directory+ExtractFileName(Application.ExeName), _STARTMENU, 'QualityCheck',Directory,'','', 'MeinProgramm.lnk');
        Result:=Directory+ExtractFileName(Application.ExeName);
      end else
        RaiseLastOSError;
    end else
      RaiseLastOSError;
  end;
end;

Mit den richten Anmeldedaten komme ich auch bis zum

Delphi-Quellcode:

ForceDirectories

in der Methode "LocalInstallation". Da kommt immer "Zugriff verweigert" (Nehme zum Testen lokales Administratorkonto). Wenn ich mich als Administrator im Windows anmelde kann ich im Windows-Explorer den Ordner ohne weitere Probleme anlegen. (Windows 10)

Nutze ich ImpersonateLoggedOnUser falsch? Oder gibt es für sowas eine besser Möglichkeit?

[Der schöne Günther]

Das Impersonate gibt dem Prozess nicht plötzlich Adminrechte. Entweder ein Prozess wird mit Adminrechten gestartet, oder ohne. Das lässt sich nicht nachträglich ändern.

PS: Ich würde vielleicht auch hinterfragen ob das Programm wirklich für alle Benutzer unter C:\Programme installiert werden muss. Seit Windows 7 gibt es

Delphi-Quellcode:

FOLDERID_UserProgramFiles

, also C:\Users\Jupp\AppData\Local\Programs. Da braucht auch kein Mensch Adminrechte für, weil das ist ja nur für Jupp.

Selbst Anwendungen wie z.B. Visual Studio Code installieren sich standardmäßig dorthin.

[TiGü]

Speichere dein Programm doch unter CSIDL_APPDATA ab und gut ist.
Musste keine Handstände mit den Rechten machen, nur weil du versuchst unter CSIDL_PROGRAM_FILESX86 etwas abzulegen.

[Der schöne Günther]

Das ist aber "roaming" AppData (nicht lokal) und würde über jeden PC mit dem Benutzerkonto synchronisiert werden. Ich hätte das eher verstanden dass AppData\Local das richtige ist, denn manche PCs stehen außerhalb und greifen über eine langsame VPN-Verbindung zu, manche stehen im schnellen Firmennetz und brauchen das nicht.

[Moombas]

Und nicht das hier ein Denkfehler geschieht "User mit Adminrechten" <> Administratoruser (unter Windows 10 zumindest).

[Hobbycoder]

Zitat:

Zitat von Der schöne Günther (Beitrag 1463191)

Das Impersonate gibt dem Prozess nicht plötzlich Adminrechte. Entweder ein Prozess wird mit Adminrechten gestartet, oder ohne. Das lässt sich nicht nachträglich ändern.

PS: Ich würde vielleicht auch hinterfragen ob das Programm wirklich für alle Benutzer unter C:\Programme installiert werden muss. Seit Windows 7 gibt es

Delphi-Quellcode:

FOLDERID_UserProgramFiles

, also C:\Users\Jupp\AppData\Local\Programs. Da braucht auch kein Mensch Adminrechte für, weil das ist ja nur für Jupp.

Selbst Anwendungen wie z.B. Visual Studio Code installieren sich standardmäßig dorthin.

Hm..ja. Macht Sinn. Ich werden den ..\AppData\Local\Programs nehmen.

Aber trotzdem würde mich interessieren wofür die Funktion Impersonate dann verwendet wird?
Ich hatte das hier: https://www.delphipraxis.net/113712-...anfordern.html entnommen.

[Delphi.Narium]

Tippe mal darauf, dass ein danach gestarteter Prozess dann mit den entsprechenden Rechten läuft.

Wenn Dein Programm eine zweite Instanz seiner selbst startet, sollte es gehen. Mit 'nem Aufrufparameter versehen, sollte sich das für den Anwender unsichtbar realisieren lassen.

Oder per CreateProcessAsUser eine zweite Instanz starten, die die Installation übernimmt.

[TiGü]

Zitat:

Zitat von Der schöne Günther (Beitrag 1463197)

Das ist aber "roaming" AppData (nicht lokal) und würde über jeden PC mit dem Benutzerkonto synchronisiert werden. Ich hätte das eher verstanden dass AppData\Local das richtige ist, denn manche PCs stehen außerhalb und greifen über eine langsame VPN-Verbindung zu, manche stehen im schnellen Firmennetz und brauchen das nicht.

Ja stimmt, dann den Pfad, den du in deinen Edit im Beitrag davor genannt hast!

[himitsu]

Zitat:

Zitat von Der schöne Günther (Beitrag 1463191)

Das Impersonate gibt dem Prozess nicht plötzlich Adminrechte. Entweder ein Prozess wird mit Adminrechten gestartet, oder ohne. Das lässt sich nicht nachträglich ändern.

Das stimmt so nicht ganz. Es lassen sich sogar einzelne Threads mit unterschiedlichen Rechten ausführen,
aber es ist einfacher die Rechte direkt beim Start eines Prozesses/Threads festzulegen, bzw. kurz nach dem Start umzuschalten.

Im Puff und hier Forum (Luckie) sollten es einige Beispiele und Tutorials zu finden sein.



Und Ja, Admin ist nicht gleich Admin.
Darum rauchen auch viele alte Codes (aus Zeiten von NT/XP) gern ab, weil sie nicht HabIchAdminrechte HabIchDiesesOderJenesRecht sondern BinIchAdministrator prüfen.

Zitat:

Zitat von Moombas (Beitrag 1463200)

Und nicht das hier ein Denkfehler geschieht "User mit Adminrechten" <> Administratoruser (unter Windows 10 zumindest).

Das ist schon seit WinNT so.

Ich hatte mal ausversehn meinem Administator sämtliche Rechte geklaut ... der durfte dann weniger als ein Gast, obwohl der Administrator hieß und in der Gruppe Administratoren war.

[Moombas]

Gut, seit wann dem so ist hätte ich nicht gewusst aber erst bei Win10 ist mir das mal auf die Füße gefallen :stupid:

Und einige denken da halt nicht dran und setzen das Gedanklich gleich.

[Hobbycoder]

Zitat:

Zitat von himitsu (Beitrag 1463209)

Das stimmt so nicht ganz. Es lassen sich sogar einzelne Threads mit unterschiedlichen Rechten ausführen,
aber es ist einfacher die Rechte direkt beim Start eines Prozesses/Threads festzulegen, bzw. kurz nach dem Start umzuschalten.

Im Puff und hier Forum (Luckie) sollten es einige Beispiele und Tutorials zu finden sein.

Wenn ich mir Luckie's Beispiel auf o.g. Url anschaue ist es ja das, was ich eben so verwende. Müsste dann nicht die weiteren Routinen (ForceDirectories) unter dem entsprechenden Benutzerkontext (Also der mit dem ich mich im Impersonate angemeldet habe) ausgeführt werden?

PS: In Luckie's Bespiel ist noch ein ReversToItself enthalten. Ist das auch aus der API?

[himitsu]

Schon mit Vista fing der Spaß mit UAC und Co. an, wo die Rechte der gestarteten Programme nicht mehr direkt mit den Rechten des eingeloggten Benutzers übereinstimmen.

RevertToSelf

Der Rest des Programms läuft ja noch mit geringeren Rechten, da sollte die Zeit mit den höheren Rechten nicht unbegrenzt andauern. (nur so lang wie nötig)
Entweder schnell wieder zurücksetzen oder den jeweiligen Thread beenden.
Damit böse Buben es nicht zu einfach ausnutzen können sich in dein Programm zu hacken und von da in den Thread zu kommen.

Wenn man z.B. auf einen anderen Desktop kommen will, dann geht das nur direkt beim Start des Threads, bevor die Messagebehandlung anläuft.
Siehe Anmeldebildschirm oder die UAC-Passwortabfrage. So Manches geht nur, wenn es noch nicht andersweitig initialisiert/benutzt wurde
und in punkto Sicherheit sollte man sicherheitshalber nichts zu lange unsicher lassen.



Zwischen Impersonate und Revert wird jeder Code in diesem Thread mit dessen Rechten ausgeführt, also eigentlich auch ein ForceDirectories.
Es gibt noch ein paar Fallstricke mit Dingen die zwar in dem Thread aufgerufen/gestartet, aber in einem anderen Thread ausgeführt werden.

[Der schöne Günther]

Es gibt keinen "Rest" des Programms. Es hat auch nichts wirklich mit Rechten eines Benutzers zu tun. Entweder der Prozess hat beim Start Admin-RechteFähigkeiten mitbekommen, oder er hat sie nicht. Man durch diese "Impersonation" sich als anderer Benutzer ausgeben, auf dessen Resourcen (z.B. Registry oder Dateien) zugreifen, aber die Admin-Fähigkeiten kommen dadurch nicht nach.

Das ist auch einer der Gründe weshalb ich bei diesen klassischen alten "setup.exe" am Schluss nie das Häkchen "Anwendung direkt starten" (oder so ähnlich) anhake, denn das Setup vererbt die Admin-Fähigkeiten gleich an den zu startenden Prozess weiter. Zumindest die allermeisten.

[Aviator]

Zitat:

Zitat von Der schöne Günther (Beitrag 1463220)

Das ist auch einer der Gründe weshalb ich bei diesen klassischen alten "setup.exe" am Schluss nie das Häkchen "Anwendung direkt starten" (oder so ähnlich) anhake, denn das Setup vererbt die Admin-Fähigkeiten gleich an den zu startenden Prozess weiter. Zumindest die allermeisten.

Haha. Ich dachte, ich wäre der Einzige der das so macht. Ich nehme den Haken auch immer raus und starte die Anwendung lieber aus dem Startmenü von Hand.

[Assarbad]

Zitat:

Zitat von Der schöne Günther (Beitrag 1463191)

Das Impersonate gibt dem Prozess nicht plötzlich Adminrechte. Entweder ein Prozess wird mit Adminrechten gestartet, oder ohne. Das lässt sich nicht nachträglich ändern.

Öhm ... also ImpersonateLoggedOnUser gibt in der Tat dem Thread die Rechte des Nutzers dessen Identität man annimmt. Himitsu erwähnte es bereits.

Kann es sein, daß du eher das hier meinst? Denn die von dir beschriebene Abgrenzung gibt es meines Wissens nach dort, aber nicht auf der Ebene um welche sich die Frage dreht. Ich lasse mich gern eines besseren belehren.

Zitat:

Zitat von Der schöne Günther (Beitrag 1463191)

Selbst Anwendungen wie z.B. Visual Studio Code installieren sich standardmäßig dorthin.

Faszinierend, oder? Entgegen Microsofts eigenen Empfehlungen. Nunja. Vermutlich liegt's daran, daß VSCode Electron-basiert ist?!

Zitat:

Zitat von Moombas (Beitrag 1463200)

Und nicht das hier ein Denkfehler geschieht "User mit Adminrechten" <> Administratoruser (unter Windows 10 zumindest).

Definiere:

1. Adminrechte
2. Adminstratoruser

Also redest du über RID=500 (DOMAIN_USER_RID_ADMIN)? Oder geht es um die "Privileges" (ich meine eingedeutscht hießen die Benutzerrechte)?

Zitat:

Zitat von Der schöne Günther (Beitrag 1463220)

Es gibt keinen "Rest" des Programms. Es hat auch nichts wirklich mit Rechten eines Benutzers zu tun. Entweder der Prozess hat beim Start Admin-RechteFähigkeiten mitbekommen, oder er hat sie nicht. Man durch diese "Impersonation" sich als anderer Benutzer ausgeben, auf dessen Resourcen (z.B. Registry oder Dateien) zugreifen, aber die Admin-Fähigkeiten kommen dadurch nicht nach.

Sicher? Du bist dir da so 100%ig sicher, daß du das hier Hilfesuchenden als definitive Aussage präsentierst? Woher genau bekommst du denn das Token? Normalerweise wird das LogonUser oder Tokenklau sein. Und wenn du dich in LogonUser als Admin ausgewiesen hast, bekommst du selbstverfreilich die entsprechenden Rechte. Wie genau definierst du "Admin-Fähigkeiten"? Das ist ja gerade der Zweck dieser Funktionen.

Ich verweise auf Mimikatz (siehe auch GitHub).

Die Lektüre des Codes von SuRun empfiehlt sich ebenfalls.

Also entweder reden wir aufgrund mangelnder gemeinsam akzeptierter Definition von "Admin-Fähigkeiten" aneinander vorbei, oder du bist auf dem Holzweg.

[Aviator]

Zitat:

Zitat von Assarbad (Beitrag 1463243)

Zitat:

Zitat von Der schöne Günther (Beitrag 1463191)

Selbst Anwendungen wie z.B. Visual Studio Code installieren sich standardmäßig dorthin.

Faszinierend, oder? Entgegen Microsofts eigenen Empfehlungen. Nunja. Vermutlich liegt's daran, daß VSCode Electron-basiert ist?!

Naja, bei VSCode gibt es zwei verschiedene Installer. Einen User Installer und einen System Installer. Der User Installer ist wohl nur verfügbar, um das Updaten und ggf. installieren von Erweiterungen zu vereinfachen. Im gewerblichen Umfeld in einer Domain bei der die User keine Admin Rechte haben sollten, sehe ich das als nützlich an.
Nachteilig sehe ich es für die Benutzer, die gerne Anwendungen auf anderen Festplatten auslagern, dazu zähle ich mich auch. Dadurch, dass der User Installer aber ins Benutzerprofil installiert wird und dieses in der Regel auf dem gleichen Laufwerk liegt wie die Windows Installation, funktioniert das nicht und der Speicher wird dort verbraucht.

Aber ich glaube, das geht jetzt langsam etwas am Thema vorbei. :oops:

[Assarbad]

Zitat:

Zitat von Aviator (Beitrag 1463248)

Nachteilig sehe ich es für die Benutzer, die gerne Anwendungen auf anderen Festplatten auslagern, dazu zähle ich mich auch. Dadurch, dass der User Installer aber ins Benutzerprofil installiert wird und dieses in der Regel auf dem gleichen Laufwerk liegt wie die Windows Installation, funktioniert das nicht und der Speicher wird dort verbraucht.

Klick, klick (/j) :zwinker: ... ja, gibt's seit Windows 2000. Und so lange benutze ich das auch schon.

[Aviator]

Zitat:

Zitat von Assarbad (Beitrag 1463254)

Zitat:

Zitat von Aviator (Beitrag 1463248)

Nachteilig sehe ich es für die Benutzer, die gerne Anwendungen auf anderen Festplatten auslagern, dazu zähle ich mich auch. Dadurch, dass der User Installer aber ins Benutzerprofil installiert wird und dieses in der Regel auf dem gleichen Laufwerk liegt wie die Windows Installation, funktioniert das nicht und der Speicher wird dort verbraucht.

Klick, klick (/j) :zwinker: ... ja, gibt's seit Windows 2000. Und so lange benutze ich das auch schon.

Ich kenne das, klar. Aber es gibt auch Leute, die so etwas nicht kennen oder auch nicht nutzen wollen. Ich gehöre eher zu letzteren. :)

[Assarbad]

Zitat:

Zitat von Aviator (Beitrag 1463256)

Ich kenne das, klar. Aber es gibt auch Leute, die so etwas nicht kennen oder auch nicht nutzen wollen. Ich gehöre eher zu letzteren. :)

Ja gut, dann kann ich dir auch nicht helfen :zwinker:

Ich benutze das schon seit weit über einer Dekade um bspw. das Profil von Browser und Email-Programm in einen verschlüsselten Container zu verbannen. Ganz selten habe ich damit auch andere Daten (bspw. riesige Spiele) "ausgelagert" oder Programme welche sich selbst zickig anstellen, wenn sie nicht auf der Systemplatte landen. Keine Ahnung warum man das nicht einsetzen wollen würde. Es hat jedenfalls nicht die gleichen Sicherheitsimplikationen wie symbolische Links und braucht daher auch nicht das entsprechende Benutzerrecht.

[Der schöne Günther]

Zitat:

Zitat von Assarbad (Beitrag 1463243)

Also entweder reden wir aufgrund mangelnder gemeinsam akzeptierter Definition von "Admin-Fähigkeiten" aneinander vorbei

Ich denke das ist es. Oder ich hatte zu wenig Kaffee.


Ganz konkret:

• Zwei Benutzer, "localUser" und "localAdmin". Ersterer gehört nicht zur Gruppe "Administratoren", letzterer schon
• Eine aktive Sitzung im Benutzer "localUser". Der Benutzer doppelklickt unseren Prozess
• Der Prozess hat in seinem Manifest, wie wohl so ziemlich jeder,
  Delphi-Quellcode:

  requestedExecutionLevel
  level="asInvoker"

• Der Prozess soll nun das Verzeichnis C:\Program Files\Watzn erstellen.

Kann er das? Dein Beitrag liest sich so als ginge das. Wenn ja, was ist dann hieran falsch?

Delphi-Quellcode:

uses
  System.SysUtils,
  WinApi.Windows;

const
   adminName = 'localAdmin';
   adminPwd = 'localAdmin';

function getAdminToken(): THandle;
begin
   Win32Check( LogonUser(
      adminName,
      nil,
      adminPwd,
      LOGON32_LOGON_INTERACTIVE,
      LOGON32_PROVIDER_DEFAULT,
      Result
   ) );
end;

procedure p();
var
   adminToken: THandle;
begin
   adminToken := getAdminToken();
   try
      Win32Check( ImpersonateLoggedOnUser(adminToken) );
      try
         Win32Check( CreateDirectory('C:\Program Files\Watzn', nil) );
      finally
         Win32Check( RevertToSelf() );
      end;
   finally
      CloseHandle(adminToken);
   end;
end;

Selbst bei TeamViewer kann man das beobachten: Der Benutzer führt einen TeamViewer-QuickSupport aus. Authentifiziert sich jemand von außen mit den Kontodaten eines Administrator-Accounts startet TeamViewer sich selbst noch einmal und beendet sich dann. So kannte ich es bislang.

[Assarbad]

Zitat:

Zitat von Der schöne Günther (Beitrag 1463259)

Ganz konkret:

• Zwei Benutzer, "localUser" und "localAdmin". Ersterer gehört nicht zur Gruppe "Administratoren", letzterer schon
• Eine aktive Sitzung im Benutzer "localUser". Der Benutzer doppelklickt unseren Prozess
• Der Prozess hat in seinem Manifest, wie wohl so ziemlich jeder,
  Delphi-Quellcode:

  requestedExecutionLevel
  level="asInvoker"

• Der Prozess soll nun das Verzeichnis C:\Program Files\Watzn erstellen.

Kann er das?

asInvoker bezieht sich auf UAC, welches bekanntlich nur wenig mit Sicherheit zu tun hat (siehe auch hier).

Bei standardmäßig gesetzten Zugriffslisten (ACLs) sollte das nicht erfolgreich sein. Aaaaber, es gibt noch die UAC File Virtualization (der entsprechende Minifilter kann per fltmc unter dem Eintrag luafv gefunden werden), welche den Zugriff transparent auf einen anderen Ordner umleitet auf den der (unprivilegierte) Anwender sehr wohl Zugriff hat (UAC muß dafür natürlich aktiviert sein).

Ich weiß also noch immer nicht, ob es dir um Admin (entsprechende Benutzerrechte und Gruppenzugehörigkeit), oder um Elevation (UAC) oder um Mandatory Integrity Control (MIC) geht.

Zitat:

Zitat von Der schöne Günther (Beitrag 1463259)

Dein Beitrag liest sich so als ginge das.

Unter der genannten Bedingung kann das gehen, ja.

Dein Delphicode sollte auch das tun was man annimmt, da sich der Admin ja über LogonUser dem System gegenüber ausweist. Kommt natürlich auf die involvierten Integrity-Level an. Sprich: zwar kann ein einzelner Thread "Admin werden", aber er unterliegt trotzdem noch MIC.

Zitat:

Zitat von Der schöne Günther (Beitrag 1463259)

Selbst bei TeamViewer kann man das beobachten: Der Benutzer führt einen TeamViewer-QuickSupport aus. Authentifiziert sich jemand von außen mit den Kontodaten eines Administrator-Accounts startet TeamViewer sich selbst noch einmal und beendet sich dann. So kannte ich es bislang.

Genau, das klingt jetzt wiederum stark nach MIC.

[Der schöne Günther]

Zitat:

Zitat von Assarbad (Beitrag 1463268)

Ich weiß also noch immer nicht, ob es dir um Admin (entsprechende Benutzerrechte und Gruppenzugehörigkeit), oder um Elevation (UAC) oder um Mandatory Integrity Control (MIC) geht.

Mir geht es eigentlich nur um die Frage des Themen-Erstellers.

Wir sind mittlerweile angekommen bei wilden Abkürzungen wie MIC, UAC, ACL, RID und was weiß ich noch, aber wenn es um das eigentliche Problem geht kommt wieder "kann gehen", "sollte" und "müsste".

Ich bekomme es nicht hin, ohne Neustarten des "normal doppelgeklickten" Prozesses ein Verzeichnis unter C:\Programme anzulegen. Vielleicht du? Dann könnten wir alle davon lernen.

[Assarbad]

Zitat:

Zitat von Der schöne Günther (Beitrag 1463269)

Wir sind mittlerweile angekommen bei wilden Abkürzungen wie MIC, UAC, ACL, RID und was weiß ich noch, aber wenn es um das eigentliche Problem geht kommt wieder "kann gehen", "sollte" und "müsste".

Wenn man mit den Sicherheitsmechanismen von Windows umgehen will, sollten diese "wilden Abkürzungen" eben geläufig sein. Ich hab ja auch absichtlich verlinkt, damit man sich notfalls schlaulesen kann.

Und ja, es kommt der Konjunktiv, weil der Fragesteller eben nicht relevante Fragen beantwortet ala UAC File Virtualization; sprich ob UAC nun aktiv ist oder nicht. Das spielt nunmal hier rein. Genauso wie MIC reinspielt, welches ja wiederum über "Elevation" mit UAC verbunden ist.

Zitat:

Zitat von Der schöne Günther (Beitrag 1463269)

Ich bekomme es nicht hin, ohne Neustarten des "normal doppelgeklickten" Prozesses ein Verzeichnis unter C:\Programme anzulegen.

Liegt nah und weist auf MIC in Aktion hin.

Ich hab kein Windows zur Hand um das auf die Schnelle selbst zu testen, zumal ich aktuell auf Linux unterwegs bin und komplett andere Dinge im Kopf hab. Um das zu testen empfehle ich euch mal den Process Explorer zur Hand zu nehmen, da kann man die Spalten Virtualization (da geht's um die UAC File Virtualization) und Integrity Level aktivieren. Zusammen mit Process Monitor sieht man dann sehr schnell warum es nicht klappt.

Das Problem ist, daß du gleich mehrere Dimensionen mit folgender Aussage

Zitat:

Zitat von Der schöne Günther (Beitrag 1463191)

Das Impersonate gibt dem Prozess nicht plötzlich Adminrechte. Entweder ein Prozess wird mit Adminrechten gestartet, oder ohne. Das lässt sich nicht nachträglich ändern.

total verkürzt. Und daher ja meine Frage an dich, was du unter Admin-Fähigkeiten bzw. Adminrechten verstehst.

Je nachdem was man darunter faßt, stimmt deine Aussage eben oder nicht. So allgemein stimmt die Aussage aber eben nicht.

Oder um es anders auszudrücken: deine Diagnose hat fachliche Schwächen, aber dein Fazit dürfte weiterhin gelten.

[Hobbycoder]

Okay, ich bin durch eure Diskussion leicht verwirrt. Soll/muss/kann es jetzt gehen oder nicht?

In meinem o.g. Code hier bekomme ich ja bei korrekten Anmeldedaten (in meinem Fall vom lokalen Administrator) vom Impersonate ein True zurück, was ja nun bedeutet, dass diese Anmeldung korrekt war. Das darauf folgende ForceDirectories im Programme-Order schlägt jedoch fehl mit "Zugriff verweigert".

Heißt das jetzt, dass die Funktion Impersonate lediglich dazu verwendet werden kann ein fremden Userkontext zu laden, oder könnte man tatsächlich systemweit als dieser Benutzter handeln, sprich eben Dinge tun, die dem Administrator vorbehalten sind.

Denn das:

Zitat:

Zitat von Assarbad (Beitrag 1463243)

Öhm ... also ImpersonateLoggedOnUser gibt in der Tat dem Thread die Rechte des Nutzers dessen Identität man annimmt. Himitsu erwähnte es bereits.

widerspricht dem:

Zitat:

Zitat von Der schöne Günther (Beitrag 1463220)

Man durch diese "Impersonation" sich als anderer Benutzer ausgeben, auf dessen Resourcen (z.B. Registry oder Dateien) zugreifen, aber die Admin-Fähigkeiten kommen dadurch nicht nach.

[Assarbad]

Zitat:

Zitat von Hobbycoder (Beitrag 1463328)

Denn das:

Zitat:

Zitat von Assarbad (Beitrag 1463243)

Öhm ... also ImpersonateLoggedOnUser gibt in der Tat dem Thread die Rechte des Nutzers dessen Identität man annimmt. Himitsu erwähnte es bereits.

widerspricht dem:

Zitat:

Zitat von Der schöne Günther (Beitrag 1463220)

Man durch diese "Impersonation" sich als anderer Benutzer ausgeben, auf dessen Resourcen (z.B. Registry oder Dateien) zugreifen, aber die Admin-Fähigkeiten kommen dadurch nicht nach.

Nein, es widerspricht sich nicht. Beide Aussagen - wie ich in meiner (vorletzten?) Antwort herausgearbeitet habe, haben ihre Berechtigung. Sie beziehen sich auf verschiedene Aspekte.

MIC ist der Grund warum du scheiterst. Somit ist der Rat vom schönen Günter korrekt, daß du es in einen anderen Prozeß auslagern mußt, um diese "Security Boundary" zu überbrücken.

Die Frage, der bisher alle geflissentlich ausgewichen sind, ist: wie definiert ihr Adminrechte/Admin-Fähigkeiten. Denn auch mit Impersonate lassen sich durchaus noch diverse Dinge tun, die vor dem Annehmen der Adminidentität so nicht möglich gewesen wären. Daß das für die Erstellung eines Verzeichnisses an dem besagten Ort nicht reicht, hat mit MIC zu tun.

Zitat:

Zitat von Hobbycoder (Beitrag 1463328)

Heißt das jetzt, dass die Funktion Impersonate lediglich dazu verwendet werden kann ein fremden Userkontext zu laden, oder könnte man tatsächlich systemweit als dieser Benutzter handeln, sprich eben Dinge tun, die dem Administrator vorbehalten sind.

MIC gibt es "erst" seit Vista oder so. Davor reichte Impersonate durchaus um so gut wie alles als der jeweilige Benutzer zu machen.

Kurzfassung: starte die Erstellung des Verzeichnisses in einem anderen Prozeß mit höherem Integritätslevel. Es reicht dazu, wenn du bspw. dein Programm über eine Befehlszeilenoption nochmal selbst - diesmal als Admin auf entsprechendem Integritätslevel - startest.

[Hobbycoder]

Danke, dass du dir nochmal die Mühe gemacht hast, dieses mir so ausführlich klar zu machen. Jetzt ist der Groschen gefallen.
Natürlich auch Dank an alle anderen.