UserImpersonation / advapi32.dll

(28.01.2015 09:35 )Achim schrieb:  Hallo,

ich habe aktuell ein Problem, an dem ich mir die Zähne ausbeisse...

Folgende Problemstellung:
- Auf einem Rechner (am Netzwerk!) gibt es einen lokalen Order (C:\Outbox).
- Auf diesen Ordner kann nur der User "John.Connor" mit dem Passwort "HastaLaVista" zugreifen. Das kann man im Windows Explorer mit einem Rechtsklick auf den Ordner >> Eigenschaften >> Sicherheit >> Bearbeiten einstellen
- Die LabVIEW-Applikation auf diesem Rechner läuft in einem allgemeinen User-Kontext ("Labor" o. ä.), "John.Connor" ist also nicht am Rechner angemeldet
- Nun soll innerhalb der LV-Applikation mithilfe der advapi32.dll ein Zugriff auf den Ordner erfolgen, d.h. im Code sind Benutzername und Passwort von "John.Connor" fest hinterlegt.
- Über "LogonUser" und "ImpersonateLoggedOnUser" soll also im Hintergrund der Zugriff auf den gesperrten Ordner erfolgen, um da was reinzuschreiben.

Es gibt wohl zwei Möglichkeiten:
- LogonUser mit dem Parameter "LOGON32_LOGON_NETWORK", dann wird direkt ein "impersonation token" erzeugt, auf dass man mit "ImpersonateLoggedOnUser" zugreifen kann

-LogonUser mit dem Parameter "LOGON32_LOGON_NETWORK_CLEARTEXT", es wird ein "primary token" erzeugt. Dieses kann man mit "DuplicateToken" und dem "ImpersonationLevel" = "SecurityImpersonation" in ein "impersonation token" umwandeln um dann wieder "ImpersonateLoggedOnUser" aufzurufen

Ich habe das im angehängten VI vorbereitet. Beide Varianten funktionieren zwar, d.h. es kommt keine Fehlermeldunge etc., aber leider kann ich trotz erfolgreichem Logon keine Dateien schreiben (Error 8: File permission error), bzw. auch keine vorhandenen Files lesen (Error 7: File not found).

Seltsam: Nach dem erfolgreichen Logon + Impersonate kann ich mit "List Folder" den Inhalt des Ordners sehen, das funktioniert sonst nicht. Das kann man auch mit der Kommandozeile nachvollziehen.

Wenn man das ganz VI unmittelbar vor "Open File" (Breakpoint!) stoppt, und sich dann "manuell" die Rechte am Ordner "Outbox" holt und dann das VI weiterlaufen lässt, läuft das Schreiben ohne Fehler durch. Das Open File-VI interessiert sich also gar nicht für den Hintergrund-Logon, sondern "sieht" nur die Benutzerrechte des aktuell am Rechner angemeldeten Users. Ich habe in den zahlreichen Links (siehe unten) gelesen, dass die Rechte nach dem Logon für den aufrufenden Thread gelten...evtl. läuft das Open/Write/Close in einem anderen Thread?! Wie könnte man das ändern? Die cmd.exe läuft ja vermutlich auch in einem anderen Thread, das Verhalten ist ja ähnlich.

Im letzten der Links ist ein Beispiel (C++), da wird meiner Ansicht nach auch nichts anderes gemacht.

https://msdn.microsoft.com/en-us/library...85%29.aspx
https://msdn.microsoft.com/en-us/library...85%29.aspx
https://msdn.microsoft.com/en-us/library...85%29.aspx
https://msdn.microsoft.com/en-us/library...85%29.aspx
http://www.codeproject.com/Articles/2105...ersonation

Ideen?

Gruß
Achim

Grundsätzlich ist LabVIEW multithreading und VIs werden in einem von vielen möglichen Threads ausgeführt, auch verschiedene Teile eines Diagrams in unterschiedlichen Threads. Es gibt ein paar Methoden um bestimmte Threadausführung zu erzwingen in LabVIEW.

1) UI Thread: Das ist ein spezielles Subsystem in LabVIEW in dem nur ein einziger Thread besteht. Du kannst ein VI so konfigurieren dass es in diesem Thread läuft. Daneben führt LabVIEW verschiedene Interaktionen mit dem Betriebssystem in diesem Thread aus, so etwa die Messagepump die dafür sorgt dass Keyboard, Mouse und andere Events vom Betriebsystem empfangen werden, aber auch alles was mit grafischer Ausgabe (deshalb UI Thread) zu tun hat. Wenn Du dann die Impersonatelogik und den Filezugriff in so einem VI hast, wird das alles im selben Thread ausgeführt. Du solltest aber aufpassen dass Du keine VIs in diesem Thread ausführen lässt die lang dauernde oder blockierende Aufrufe ins Betriebssystem machen, ansonsten kan die Maschine blockiert erscheinen, weil LabVIEW auch keine Events verarbeiten und keinen Bildschirmaufbau mehr machen kann.

2) Ein VI das als Subroutine konfiguriert wird, wird ebenfalls als Ganzes im selben Thread ausgeführt, aber dann nicht unbedingt im UI Thread. Auch hier gilt, wenn auch etwas abgeschwächt, keine langdauernden oder blockierenden Aufrufe in so einem VI machen oder das System kann aufgehängt erscheinen.

3) Last but not least alles in eine C(++) Funktion auslagern. Die C Funktion wird von LabVIEW aus in einem der verfügbaren Threads ausgeführt aber bleibt für die gesamte Dauer in diesem Thread bis sie die Kontrolle an LabVIEW zurückgibt indem die Funktion zum Aufrufer zurückkehrt.

Was die Zahlenwerte von "Enums" (meist nicht wirklich enums sondern einfach #defines) angeht, ich habe dazu das Windows SDK installiert und benütze Notepad++ um das entsprechende Include Directory nach diesen defines suchen zu lassen. Das ist ohnehin die authoritive Quelle, MSDN ist nicht immer korrekt auch wenn die Information manchmal drinsteht.