Mapper un lecteur réseau devant être utilisé par un service
Supposons que certains services Windows utilisent du code voulant des lecteurs réseau mappés et aucun chemin UNC. Comment puis-je rendre le mappage de lecteur disponible pour la session du service au démarrage du service? Se connecter en tant qu'utilisateur du service et créer un mappage persistant n'établira pas le mappage dans le contexte du service réel.
Vous devrez soit modifier le service, soit l'intégrer dans un processus d'assistance: outre les problèmes d'accès aux sessions et aux lecteurs, les mappages de lecteurs persistants ne sont restaurés que lors d'une ouverture de session interactive, ce que les services n'effectuent généralement pas.
L'approche des processus d'assistance peut être assez simple: il suffit de créer un nouveau service qui mappe le lecteur et démarre le "vrai" service. Les seules choses qui ne sont pas entièrement triviales à ce sujet sont:
Le service d'assistance devra transmettre toutes les commandes SCM appropriées (démarrage/arrêt, etc.) au service réel. Si le service réel accepte les commandes SCM personnalisées, n'oubliez pas de les transmettre également (je ne m'attends pas à ce qu'un service qui considère les chemins UNC exotiques à utiliser de telles commandes, cependant ...)
Les choses peuvent devenir un peu délicates en ce qui concerne les informations d'identification. Si le service réel s'exécute sous un compte d'utilisateur normal, vous pouvez également exécuter le service d'assistance sous ce compte. Tout devrait fonctionner normalement tant que le compte dispose d'un accès approprié au partage réseau. Si le service réel ne fonctionne que lorsqu'il est exécuté en tant que LOCALSYSTEM ou à un autre, les choses deviennent plus intéressantes, car il ne sera plus en mesure de "voir" le lecteur réseau, ou nécessitera un certain jonglage des informations d'identification pour que les choses fonctionnent.
Utilisez ceci à vos risques et périls. (Je l'ai testé sur XP et Server 2008 x64 R2)
Pour ce piratage, vous aurez besoin de SysinternalsSuite de Mark Russinovich :
Première étape: Ouvrez une invite cmd.exe surélevée (exécutée en tant qu'administrateur).
Deuxième étape: Passez de nouveau à root avec PSExec.exe: accédez au dossier contenant SysinternalsSuite et exécutez la commande suivante psexec -i -s cmd.exe dans laquelle vous vous trouvez. d'une invite qui est nt authority\system et vous pouvez le prouver en tapant whoami. Le -i est nécessaire car les mappages de lecteurs doivent interagir avec l'utilisateur
Troisième étape: Créez le lecteur mappé persistant en tant que compte SYSTEM avec la commande suivante Net Use z: \\servername\sharedfolder /persistent:yes
C'est si facile!
WARNING: Vous ne pouvez supprimer ce mappage que de la même manière que vous l'avez créé, du compte SYSTEM. Si vous devez le supprimer, suivez les étapes 1 et 2, mais modifiez la commande de l'étape 3 en Net Use z: /delete.
NOTE: Le lecteur mappé nouvellement créé apparaît désormais pour TOUS les utilisateurs de ce système, mais ils le verront affiché comme suit: "Lecteur réseau déconnecté (Z: ) ". Ne laissez pas le nom vous tromper. Il peut prétendre être déconnecté mais cela fonctionnera pour tout le monde. C'est ainsi que vous pouvez savoir que ce piratage n'est pas pris en charge par M $.
J'ai trouvé une solution similaire à celle avec psexec mais qui fonctionne sans outils supplémentaires et survit à un redémarrage.
Ajoutez simplement une tâche planifiée, insérez "système" dans le champ "exécuter en tant que" et pointez la tâche vers un fichier de commandes à l'aide de la simple commande
Net Use z: \servername\sharedfolder /persistent:yes
Ensuite, sélectionnez "exécuter au démarrage du système" (ou similaire, je n'ai pas de version anglaise) et vous avez terminé.
Un meilleur moyen serait d'utiliser un lien symbolique à l'aide de mklink.exe. Vous pouvez simplement créer un lien dans le système de fichiers que n'importe quelle application peut utiliser. Voir http://en.wikipedia.org/wiki/NtFS_symbolic_link .
Il y a une bonne réponse ici: https://superuser.com/a/651015/299678
C'est à dire. Vous pouvez utiliser un lien symbolique, par exemple.
mklink /D C:\myLink \\127.0.0.1\c$
Vous pouvez nous utiliser la commande 'Net Use':
var p = System.Diagnostics.Process.Start("net.exe", "use K: \\\\Server\\path");
var isCompleted = p.WaitForExit(5000);
Si cela ne fonctionne pas dans un service, essayez Winapi et PInvoke WNetAddConnection2
Edit: Évidemment, je vous ai mal compris - vous ne pouvez pas changer le code source du service, n'est-ce pas? Dans ce cas, je suivrais la suggestion de mdb , mais avec une légère modification: créez votre propre service (appelons-le service de mappage) qui mappe le lecteur et ajoute ce service de mappage aux dépendances du premier (le travail réel) service. Ainsi, le service actif ne démarrera pas avant que le service de mappage ait démarré (et mappé le lecteur).
ForcePush,
NOTE: Le lecteur mappé nouvellement créé apparaît maintenant pour TOUS les utilisateurs de ce système, mais ils le verront affiché sous la forme "Lecteur réseau déconnecté (Z :)". Ne laissez pas le nom vous tromper. Il peut prétendre être déconnecté mais cela fonctionnera pour tout le monde. Voilà comment vous pouvez dire que ce hack n’est pas supporté par M $ ...
Tout dépend des autorisations de partage. Si vous avez Tout le monde dans les autorisations de partage, ce lecteur mappé sera accessible par d'autres utilisateurs. Mais si vous ne possédez que les utilisateurs dont vous avez utilisé les informations d'identification dans votre script de traitement par lots et si ce script de traitement par lots a été ajouté aux scripts de démarrage, seul le compte système aura accès à ce partage, pas même l'administrateur. Ainsi, si vous utilisez, par exemple, un travail ntbackuo planifié, le compte système doit être utilisé dans "Exécuter en tant que". Si la connexion de votre service est en tant que: compte système local, cela devrait fonctionner.
Ce que j'ai fait, je n'ai mappé aucune lettre de lecteur dans mon script de démarrage, je n'ai utilisé que Net Use \\\server\share ... et utilisé le chemin UNC dans mes travaux planifiés. Ajout d'un script d'ouverture de session (ou simplement ajout d'un fichier de commandes dans le dossier de démarrage) avec le mappage vers le même partage avec une lettre de lecteur: Net Use Z: \\\... avec les mêmes informations d'identification. Maintenant, l'utilisateur connecté peut voir et accéder à ce lecteur mappé. Il y a 2 connexions au même partage. Dans ce cas, l'utilisateur ne voit pas cet ennuyeux "Lecteur réseau déconnecté ...". Mais si vous avez vraiment besoin d'accéder à cette part par la lettre de lecteur, pas uniquement par UNC, mappez cette partition avec les différentes lettres de lecteur, par exemple. Y pour le système et Z pour les utilisateurs.
Trouver un moyen d'accorder l'accès du service Windows au lecteur réseau.
Prenez Windows Server 2012 avec un disque NFS, par exemple:
Étape 1: écrivez un fichier de commandes à monter.
Ecrire un fichier batch, ex: C:\mount_nfs.bat
echo %time% >> c:\mount_nfs_log.txt
Net Use Z: \\{your ip}\{netdisk folder}\ >> C:\mount_nfs_log.txt 2>&1
Étape 2: Montez le disque en tant qu’autorité NT/système.
Ouvrez "Planificateur de tâches", créez une nouvelle tâche:
- Exécuter en tant que "SYSTÈME", à "Démarrage du système".
- Créer une action: Exécutez "C:\mount_nfs.bat".
Après ces deux étapes simples, mon service Windows ActiveMQ s’exécute sous le privilège "Système local", fonctionne parfaitement sans connexion.
La raison pour laquelle vous pouvez accéder au lecteur lorsque vous exécutez normalement le fichier exécutable à partir de la commande Invite est que lorsque vous l'exécutez en tant qu'exe normal, vous exécutez cette application dans le compte d'utilisateur à partir duquel vous vous êtes connecté. Et cet utilisateur a les privilèges pour accéder au réseau. Mais, lorsque vous installez l'exécutable en tant que service, par défaut, si vous voyez dans la tâche à gérer, il s'exécute sous le compte 'SYSTEM'. Et vous savez peut-être que le "SYSTÈME" n'a pas le droit d'accéder aux ressources du réseau.
Il peut y avoir deux solutions à ce problème.
Pour mapper le lecteur aussi persistant que déjà indiqué ci-dessus.
Une autre approche peut être suivie. Si vous ouvrez le gestionnaire de services en tapant dans "services.msc", vous pouvez accéder à votre service. Dans les propriétés de votre service, un onglet de connexion vous permet de spécifier le compte comme n'importe quel autre compte que "Système". démarrez le service à partir de votre propre compte d'utilisateur connecté ou via "Service réseau". Lorsque vous procédez ainsi, le service peut accéder à n’importe quel composant et lecteur du réseau, même s’ils ne sont pas persistants. Pour ce faire par programme, vous pouvez examiner la fonction 'CreateService' à l'adresse http://msdn.Microsoft.com/en-us/library/ms682450 (v = vs.85) .aspx et définir le paramètre 'lpServiceStartName' à 'NT AUTHORITY\NetworkService'. Cela démarrera votre service sous le compte 'Service réseau' et vous aurez terminé.
Vous pouvez également essayer de rendre le service interactif en spécifiant SERVICE_INTERACTIVE_PROCESS dans l'indicateur de paramètre servicetype de votre fonction CreateService (), mais cela ne sera limité que jusqu'à XP, Vista et 7 ne prenant pas cette fonctionnalité en charge.
J'espère que les solutions vous aideront .. Faites-moi savoir si cela a fonctionné pour vous.
Vous ne devez pas changer l'utilisateur sous lequel le service s'exécute sous "Système" ni trouver un moyen sournois d'exécuter votre mappage en tant que système.
La chose amusante est que cela est possible en utilisant la commande "at" , planifiez simplement le mappage de votre lecteur une minute dans le futur et il sera exécuté sous le compte Système, ce qui rendra le lecteur visible pour votre service.
Au lieu de vous fier à un lecteur persistant, vous pouvez définir le script pour mapper/dé-mapper le lecteur à chaque utilisation:
Net Use Q: \\share.domain.com\share
forfiles /p Q:\myfolder /s /m *.txt /d -0 /c "cmd /c del @path"
Net Use Q: /delete
Cela fonctionne pour moi.
Je ne peux pas commenter (travail sur la réputation), mais j'ai créé un compte juste pour répondre à @Tech Jerk @ spankmaster79 (joli nom lol) et aux problèmes de @NMC signalés en réponse à la question "J'ai trouvé une solution similaire à celle avec psexec mais fonctionne sans outils supplémentaires et survit à un redémarrage. " post @Larry avait fait.
La solution à cela consiste simplement à parcourir ce dossier à partir du compte connecté, c'est-à-dire:
\\servername\share
et laissez-le invite à se connecter et entrez les mêmes informations d'identification que vous avez utilisées pour l'UNC dans psexec. Après ça commence à fonctionner. Dans mon cas, je pense que cela est dû au fait que le serveur avec le service n'est pas membre du même domaine que le serveur vers lequel je mappe. Je pense que si l'UNC et la tâche planifiée font tous deux référence à l'IP au lieu du nom d'hôte
\\123.456.789.012\share
cela peut éviter complètement le problème.
Si je reçois un nombre suffisant de points de représentation ici, je vais plutôt ajouter ceci comme réponse.