Ausführbare Datei gestartet, indem ein windows-Dienst über das lokale Systemkonto keinen Zugriff auf Netzwerkfreigaben
Ich habe eine ausführbare Datei, die gestartet wird, indem ein windows-Dienst, wird dieses Programm laufen auf einer Maschine des Kunden und müssen eine Verbindung zu einer remote-Freigabe für die Durchführung einer bestimmten Aufgabe. Dieser Anteil ist festgelegt durch den Kunden über eine Benutzeroberfläche, also das wissen wir nicht im Voraus, was bedeutet, es kann nicht "hart codiert" ist, oder die Freigabe gemappt im Voraus.
Bisher haben wir gefordert, den Kunden-log auf Ihren Computer und führen Sie die ausführbare Datei auf anmelden , aber wir haben immer wollten, um zu erlauben, dass unser Programm ausgeführt werden innerhalb eines service und nicht erfordern ein log-in Erster Linie, um es einfacher für die Kunden, und verhindern jede versehentliche log-outs Herunterfahren unserer software. Also das bedeutet auch, dass wir nicht wissen, welche lokalen Benutzerkonten auf einer Maschine des Kunden, so dass wir beginnen müssen, die der Dienst über das lokale Systemkonto.
Wir haben nun, wie oben erwähnt, eine wrapper-service zu starten Sie die ausführbare Datei und führen Sie verschiedene Aufgaben. Dies scheint gut zu funktionieren in den meisten Fällen und greift auf die zugrunde liegenden Netzwerk-fein - unsere software hat den Zweck betrifft vor allem die Erfassung von Paketen etc.
Jedoch, wenn die software versucht, eine Verbindung zu einer windows-Freigabe (UNC-Namen), kann es nicht verbinden. In der Erwägung, dass, wenn die ausführbare Datei manuell gestartet wurde, die es verbindet, fein.
Die Vorschläge, die ich habe, generell gesehen, zu lösen diese Art von Problemen scheinen alle sagen, ein Benutzerkonto verwenden, da das system-Konto zugreifen können Netzwerkfreigaben, aber in unserem Fall ist dies nicht möglich. Gibt es eine andere Möglichkeit, wir könnten diese zu arbeiten?
Edit: ich vergaß zu erwähnen, dass diese Anwendung kann (und meist wird) laufen auf Win2K nicht XP, und ich glaube, ich bin zu Recht sagen, dass die Lokalen Netzwerk-Konto ist nicht verfügbar, bevor XP?
Du musst angemeldet sein, um einen Kommentar abzugeben.
Wenn Sie ändern, können Sie Ihre windows-Dienst, so dass es läuft unter dem Network Service account, dann wird die ausführbare Datei wird in der Lage sein, Zugriff auf Netzwerk-Freigaben (dies ist einer der Gründe, warum das Network Service-Konto erstellt wurde).
Dem Lokalen System und Lokale Dienstkonten nicht irgendwelche Netzwerk-Anmeldeinformationen, und kann somit nicht im Netzwerk authentifiziert wurden. Das ist by design.
Edit: IIRC, das Netzwerkdienst-Konto wurde eingeführt, Server 2003, und Hinzugefügt, um einen der XP-service-packs.
Wenn Sie sich nicht darauf verlassen kann das Network Service-Konto zur Verfügung stehen, dann könnten Sie erwägen, eine dedizierte Domäne-Kontos, die Speicherung der Anmeldedaten irgendwo zu Lesen, die Sie aus in Ihrem Dienst, dann loging und die Identität, die der Benutzer vor dem Zugriff auf die Netzwerkfreigabe. Alternativ können Sie den windows-Dienst laufen konnte als dediziertes Konto direkt, in dem Fall würde es erfordern, die "als Dienst anmelden" - Berechtigung.
Wenn Sie einen Dienst unter NT AUTHORITY\LOCALSYSTEM (das ist der name der service-account), es wird als DOMÄNENNAME\COMPUTERNAME$ (beachten Sie das $ - Zeichen) dem rest des Netzwerks. Das heißt, es wird angezeigt, wie der COMPUTER das Konto in Active directory. Sie einfach gewähren, Ihre Datei-und Freigabeberechtigungen zu DOMÄNENNAME\COMPUTERNAME$ ist und Sie sollte gut sein.
Warum kann man nicht ein anderes Konto verwenden? Es ist ein Netzwerk-service-Konto in Windows integriert, die speziell für die Dienste, die benötigen Zugriff auf das Netzwerk.
Sowieso sehr vorsichtig sein, wenn Sie einen Dienst starten einer exe-Datei.
Wenn der Schreibzugriff auf den Ordner mit der exe-Datei wird nicht deaktiviert, ein Benutzer kann ersetzen, dass die exe-Datei mit (beispielsweise)
cmd.exe
. Das nächste mal, wenn der Dienst versucht, starten Sie Ihre exe, voilà: Eine Befehls-shell mit system-rechten!