Ich habe einen Legacy-Windows-Serverdienst und eine (erzeugte) Anwendung, die in XP-64 und W2K3 einwandfrei funktioniert, aber unter W2K8 nicht funktioniert. Ich glaube, es ist wegen der neuen Funktion " Sitzung 0 Isolation ".
Daher suche ich nach Code-Beispielen / Sicherheitseinstellungen, mit denen Sie einen neuen Prozess von einem Windows-Dienst für Windows 2008 Server erstellen können, sodass ich das vorherige Verhalten wiederherstellen (und möglicherweise sogar übertreffen) kann. Ich brauche eine Lösung, die:
Weil Sitzung 0 kein Benutzer mehr ist Sitzung, Dienste, die ausgeführt werden Sitzung 0 hat keinen Zugriff auf die Grafiktreiber. Dies bedeutet, dass alle versuchen, dass ein Dienst zum Rendern macht Grafik schlägt fehl. Abfrage der Anzeige Auflösung und Farbtiefe in Session 0 meldet die korrekten Ergebnisse für die System bis zu einem Maximum von 1920x1200 bei 32 Bits pro Pixel.
Der neue Prozess erhält eine Windows-Station / einen Windows-Desktop (z. B. winsta0 / default), der zum Erstellen von Windows-DCs verwendet werden kann. Ich habe hier eine Lösung gefunden (die OK in einer interaktiven Sitzung startet): Starten eines interaktiven Client-Prozesses in C ++
Die Windows-DC, wenn sie als Grundlage für eine OpenGL DescribePixelFormat-Enumeration verwendet werden , ist in der Lage, das hardwarebeschleunigte Format zu finden und zu verwenden (auf einem System, das mit OpenGL-Hardware ausgestattet ist). Beachten Sie, dass unsere aktuelle Lösung auf XP-64 und W2K3 funktioniert, außer wenn eine Terminaldienstesitzung läuft (VNC funktioniert einwandfrei). ) Eine Lösung, die es auch erlaubt, dass der Prozess funktioniert (dh mit OpenGL-Hardwarebeschleunigung läuft, selbst wenn eine Terminaldienstesitzung geöffnet ist) wäre fanatisch, obwohl nicht erforderlich.
Ich stecke momentan an Punkt # 1, und obwohl es ähnliche Einträge gibt, die das diskutieren (wie dies und dies - sie sind keine geeigneten Lösungen, da es keine Garantie für eine bereits eingeloggte Benutzersitzung gibt" Nehme "eine Sitzungs-ID von, noch laufe ich von einem LocalSystem-Account ab (ich laufe von einem Domain-Account für den Service, für den ich die Berechtigungen anpassen kann, im Rahmen des Zumutbaren, obwohl ich es lieber nicht eskalieren möchte Prioritäten, um SeTcbPrivileges einzuschließen.)
Zum Beispiel - hier ist ein Stub, der meiner Meinung nach funktionieren sollte, aber immer einen Fehler 1314 beim Aufruf von SetTokenInformation zurückgibt (obwohl AdjustTokenPrivileges keine Fehler zurückgegeben hat). Ich habe auch alternative Strategien mit "LogonUser" verwendet Öffnen des vorhandenen Prozesstokens), aber ich kann die Sitzungs-ID anscheinend nicht austauschen.
Ich bezweifle auch, dass ich die WTSActiveConsoleSessionId in allen Fällen verwende (zum Beispiel wenn kein interaktiver Benutzer angemeldet ist) - obwohl ein schneller Test des Dienstes, der ohne eingeloggte Sitzungen läuft, einen angemessenen Sitzungswert zu liefern scheint (1 ).
Ich habe die Fehlerbehandlung aus Gründen der Lesefreundlichkeit entfernt (immer noch etwas unordentlich - Entschuldigung)
%Vor%Die gesamte Debug-Ausgabe sieht bis zum SetTokenInformation-Aufruf gut aus. Ich sehe, dass Sitzung 0 meine aktuelle Prozesssitzung ist und in meinem Fall versucht, Sitzung 1 zu setzen (das Ergebnis der WTSGetActiveConsoleSessionId). (Beachten Sie, dass ich über VNC, nicht RDC, in die W2K8-Box eingeloggt bin)
Also - a die Fragen:
Jede Hilfe sehr geschätzt - danke!
Für alle, die an der Lösung dieses Problems interessiert sind:
Ich habe dieses Problem mit dem MS Support für das LogonSDK-Team besprochen. Es scheint, dass es nicht möglich ist, einen interaktiven Benutzer programmatisch vollständig zu imitieren, so dass Sie eine physische Konsole und damit verbundene GDI-Konstrukte erhalten, und wir waren im Wesentlichen "nur glücklich", dass es bis jetzt funktioniert hat. Sie haben bestätigt, dass die Isolation der Sitzung 0 die Ursache der Regression war.
Sie empfehlen, die automatische Anmeldung an einer interaktiven Sitzung zu aktivieren und den Dienst so zu reformieren, dass er in der interaktiven Sitzung mit einer neuen Clientkomponente spricht. Um den Sicherheitsnachteil zu beheben, empfiehlt es sich, einen Shell-Ersatz zu implementieren, um den Server bei der Anmeldung in einen "Kiosk" -Modus zu versetzen (z. B. kein Explorer-Zugriff ohne entsprechende Anmeldeinformationen usw.).
Auf der anderen Seite sollte dies die Probleme beheben, mit denen wir bei Terminaldienstsitzungen konfrontiert wurden, die unsere Hardwarebeschleunigung zunichte machten.
Ich werde eine Anfrage an MS senden, diese Art von "render farm" Anwendungsfall für die "Proxy User Session" Unterstützung in zukünftigen Versionen zu berücksichtigen, so dass ein Server hardwarebeschleunigte Prozesse generieren kann, ohne dass ein existierender kompromittiert werden muss Clientbenutzerprozess, der an der Konsole angemeldet wird.
farmComm startet die Anwendung (en) Ihrer Wahl in Sitzung 0, ohne GUI sichtbar, aber mit Zugriff auf Grafikhardware, unabhängig davon, ob Benutzer angemeldet sind oder nicht. Sie reagiert auch auf Benutzeraktivitäten in jeder aktiven Sitzung (einschließlich Sitzung 0 oder "sicherer Desktop", wenn dies die aktive Sitzung ist). Es wurde entwickelt, um Anwendungen zu starten, wenn Benutzer im Leerlauf sind, und sie zu beenden, wenn der Benutzer aus dem Leerlauf zurückkehrt, aber diese Laufbedingungen können leicht in den Quell-AutoHotkey-Skripten geändert werden.
Es erzeugt Anwendungen in Sitzung 0 "unsichtbar", kann aber sehr leicht geändert werden (eine Variable mit dem Wert "hide" in "show" ändern), um die GUIs von erzeugten Prozessen sichtbar zu machen (wenn sie eine GUI haben) . Wenn sie jedoch sichtbar sind, können sie entweder Windows-Nags veranlassen, "Nachrichten" in Sitzung 0 zu sehen, und / oder nur von Sitzung 0 sichtbar sein (die, wie es scheint, jedes Mal, wenn der "sichere Desktop" sichtbar ist - für Beispiel, wenn eine Arbeitsstation gesperrt oder von Benutzersitzungen getrennt oder keine Benutzer angemeldet sind.)
Wenn eine Remotedesktopsitzung (RDP) gestartet wird, während von farmComm erzeugte Prozesse ausgeführt werden, beendet farmComm diese Prozesse und versucht, sie erneut zu starten, um auf die RDP-Sitzung zu antworten, bei der es sich um Anwendungen handelt Der Versuch, auf Grafikhardware zuzugreifen, kann zum Absturz führen (weil RDP den Zugriff auf Grafikhardware einschränkt). Wahrscheinlich könnte dieses RDP-Problem ebenfalls gelöst werden. . . oder Sie können die Quelle zwicken, um Prozesse nie zu beenden, oder nie zu anderen Sitzungen migrieren. (HINWEIS: Eine mögliche geplante Änderung besteht darin, dass Sie Skripts erstellen können, unabhängig davon, ob und wann farmComm beendet, Prozesse nicht beendet, aussetzt oder wieder aufnimmt - oder Skripts, die ganz andere Prozesse ausführen, wenn Benutzer aus dem Leerlauf zurückkehren) / p>
Die Skripte können zu ausführbaren Dateien kompiliert werden, die in meiner Distribution sind.
Die Kernpunkte dieses Toolsets sind eine bestimmte Version von paexec (die Anwendungen in Sitzung 0 startet) und AutoHotkey's sehr zuverlässige Antworten auf Benutzeraktivität (oder deren Fehlen) und das Abrufen von Systeminformationen über eine Sitzung. Die Option, Prozesse "versteckt" (ohne GUI sichtbar) zu starten, erfolgt ebenfalls über AutoHotkey.
Offenlegung: Ich habe farmComm geschrie- ben (oder codiert) und in der Public Domain veröffentlicht.