1
Process.start bricht im System Kontext mit der Meldung Zugriff verweigert
Hallo zusammen,
ich habe folgendes Problem:
Ich möchte mein Programm unter den System Kontext laufen lassen. Das Programm solle eine Anwendung starten die aber als Administrator laufen muss. Führt man den unten stehenden Code als ein Anwender aus funktioniert er.
Wenn ich aber diesen Code unter den System Kontext (z.B Systemdienst) laufen lasse bekomme ich folgende Fehlermeldung: System.ComponentModel.Win32Exception: Zugriff verweigert
Ich habe auch schon die Netzwerk-Freigabe ersetzt durch einen Pfad auf eine Anwendung die lokal auf den PC liegt, hat aber nichts gebracht.
ich habe folgendes Problem:
Ich möchte mein Programm unter den System Kontext laufen lassen. Das Programm solle eine Anwendung starten die aber als Administrator laufen muss. Führt man den unten stehenden Code als ein Anwender aus funktioniert er.
Wenn ich aber diesen Code unter den System Kontext (z.B Systemdienst) laufen lasse bekomme ich folgende Fehlermeldung: System.ComponentModel.Win32Exception: Zugriff verweigert
Ich habe auch schon die Netzwerk-Freigabe ersetzt durch einen Pfad auf eine Anwendung die lokal auf den PC liegt, hat aber nichts gebracht.
Dim P As New ProcessDim value As New System.Security.SecureStringFor Each C As Char In "passwort".ToCharArray value.AppendChar(C)NextP.StartInfo.FileName = "\\PCName\Freigabe\Software\Application.exe" P.StartInfo.Arguments = ProgrammParaP.StartInfo.UserName = "Administrator"P.StartInfo.UseShellExecute = FalseP.StartInfo.Password = valueP.StartInfo.LoadUserProfile = TrueP.Start()P.WaitForExit()
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 53018
Url: https://administrator.de/contentid/53018
Ausgedruckt am: 26.11.2024 um 03:11 Uhr
1 Kommentar
Der Thread ist mir beim durchforsten aufgefallen. und ich antworte mal obwohl der Post über ein Jahr alt ist, falls auch andere noch über Ihn stolpern.
Das Problem ist folgendes.
In einer Windows 2003 Domäne wird dieser Fall auftreten. Warum ?
Jeder dem AD-bekannte Benutzer kann sich beim AD anmelden um sich dort zu authentisieren und dann einfach viele Dinge tun. Z.b. ein RunAs starten und sich in einen anderen Userkontext switchen. Dieser UserKontext wird dann wiederum gegenüber dem AD authentisiert. Das Funktioniert aber nur weil der Ausgangsuser dem AD bereits bekannt war.
Ein SystemDienst ist dem User nicht bekannt und kann daher keine AD-Funktionen ausführen. d.h. sich nicht im AD anmelden geschweige denn in einen anderen Userkontext switchen. Dieses "Problem" mit NullSessionShares" ist ein elementares Sicherheitsfeature unter Windows 2003 Domänen.
Es ist also kein Problem deines Scriptes und es ist auch irrelevant WO du die Daten zu liegen hast die du manipulieren willst. Wichtig ist nur, dass LocalSystem nicht aufs AD zugreifen kann/soll/darf um sich erhöhte Rechte zu holen. Versuch jedoch mal anstelle eines AD-Users in den Kontext eines lokalen Admins zu switchen. Hier dürfte die AD-Security nicht greifen
Gruß, Jan
Das Problem ist folgendes.
In einer Windows 2003 Domäne wird dieser Fall auftreten. Warum ?
Jeder dem AD-bekannte Benutzer kann sich beim AD anmelden um sich dort zu authentisieren und dann einfach viele Dinge tun. Z.b. ein RunAs starten und sich in einen anderen Userkontext switchen. Dieser UserKontext wird dann wiederum gegenüber dem AD authentisiert. Das Funktioniert aber nur weil der Ausgangsuser dem AD bereits bekannt war.
Ein SystemDienst ist dem User nicht bekannt und kann daher keine AD-Funktionen ausführen. d.h. sich nicht im AD anmelden geschweige denn in einen anderen Userkontext switchen. Dieses "Problem" mit NullSessionShares" ist ein elementares Sicherheitsfeature unter Windows 2003 Domänen.
Es ist also kein Problem deines Scriptes und es ist auch irrelevant WO du die Daten zu liegen hast die du manipulieren willst. Wichtig ist nur, dass LocalSystem nicht aufs AD zugreifen kann/soll/darf um sich erhöhte Rechte zu holen. Versuch jedoch mal anstelle eines AD-Users in den Kontext eines lokalen Admins zu switchen. Hier dürfte die AD-Security nicht greifen
Gruß, Jan
