Le fichier exécutable démarré par un service Windows utilisant le compte système local ne peut pas accéder aux partages réseau

Question

J'ai un exécutable démarré par un service Windows, ce programme sera exécuté sur un ordinateur client et devra se connecter à un partage distant pour effectuer une tâche particulière. Ce partage est spécifié par le client via une interface utilisateur. Nous ne le savons donc pas à l'avance, ce qui signifie qu'il ne peut pas être "codé en dur", ni que le partage doit être mappé à l'avance.

Auparavant, nous demandions au client de se connecter à sa machine et d'exécuter l'exécutable lors de la connexion, mais nous avons toujours voulu permettre à notre programme de s'exécuter au sein d'un service et de ne pas nécessiter de connexion, principalement pour le rendre plus facile. pour le client et éviter toute déconnexion accidentelle en arrêtant notre logiciel. Cela signifie donc également que nous ne savons pas quels comptes d'utilisateurs locaux existent sur une machine client. Nous devons donc démarrer le service à l'aide du compte système local.

Nous avons maintenant, comme mentionné ci-dessus, un service d'encapsuleur pour démarrer l'exécutable et effectuer diverses tâches. Cela semble fonctionner correctement dans la plupart des cas et permet d’accéder correctement au réseau sous-jacent. Le but de notre logiciel consiste principalement à capturer des paquets, etc.

Cependant, lorsque le logiciel essaie de se connecter à un partage Windows (nom UNC), il ne peut pas se connecter. Considérant que si l’exécutable a été démarré manuellement, il se connecte correctement.

Les suggestions que j’ai généralement vues pour résoudre ce type de problèmes semblent toutes indiquer que vous utilisez un compte utilisateur car le compte système ne peut pas accéder aux partages réseau, mais dans notre cas cela n’est pas possible. Existe-t-il un autre moyen de faire en sorte que cela fonctionne?

Edit: j'ai oublié de mentionner que cette application pourrait (et le plus souvent être utilisée) s'exécuter sous Win2K et non sous XP, et je pense avoir raison de dire que le compte de réseau local n'est pas disponible avant XP?

Answer 1

Si vous pouvez modifier votre service Windows de sorte qu'il s'exécute sous le compte de service réseau, votre exécutable pourra accéder aux partages réseau (c'est l'une des raisons pour lesquelles le compte de service réseau a été créé).

Les comptes Système local et Service local ne disposent d'aucune information d'identification réseau et ne peuvent donc pas être authentifiés sur le réseau. C'est par conception.

Modifier: IIRC, le compte de service réseau a été introduit dans Server 2003 et ajouté à l'un des service packs XP.

Si vous ne pouvez pas compter sur le compte de service réseau disponible, vous pouvez envisager de créer un compte de domaine dédié, de stocker les informations d'identification du compte quelque part, de les lire depuis votre service, puis de vous connecter et de vous faire passer pour l'utilisateur avant d'accéder au réseau. partager. Sinon, le service Windows pourrait s’exécuter directement en tant que compte dédié, auquel cas il faudrait utiliser la "connexion en tant que service". privilège.

Answer 2

Lorsque vous utilisez un service exécuté sous NT AUTHORITY \ LOCALSYSTEM (nom du compte de service), il apparaît en tant que compte DOMAINNAME \ COMPUTERNAME $ (notez le signe $) sur le reste du réseau. C'est-à-dire qu'il apparaît en tant que compte de l'ordinateur dans Active Directory. Accordez simplement votre fichier et partagez les autorisations sur DOMAINNAME \ COMPUTERNAME $ et vous devriez être bon.

Answer 3

Pourquoi ne pouvez-vous pas utiliser un autre compte? Il existe un compte de service réseau intégré à Windows, spécialement pour les services nécessitant un accès réseau.

Quoi qu'il en soit, soyez très prudent lorsque vous démarrez un service avec un service.

Si l'accès en écriture au dossier avec l'exe n'est pas désactivé, un utilisateur peut remplacer cet exe par (par exemple) cmd.exe . La prochaine fois que le service essaiera de démarrer votre exe, voilà: Un shell de commande avec les droits du système!