[services windows et dot net]service account sous windows 7

Bonjour à toute la communauté!

Tout d'abord, comme il s'agit de mon premier post ici, je tenais à remercier tous les contributeurs pour les ressources de ce site, ô combien utile lorsque l'on débute (et même après ^^).

Alors voici mon souci ^^' Je viens de commencer une formation en développement C#, et j'ai besoin de synchroniser une ressource montée en tant que lecteur réseau avec un dossier local sur ma machine. Mais puisque tous mes collègues vont avoir peu ou prou le même besoin, j'aimerais le faire sous une forme distribuable.
D'où l'idée de mettre cette routine sous forme de service windows.
J'ai donc commencé par créer un objet qui gère la synchronisation (histoire de pouvoir réutiliser ce composant ailleurs au besoin), puis monté le service, puis le projet d'installation qui va avec.
En local, aucun problème, tout fonctionne.

En situation réelle, c'est une autre paire de manches... Et c'est une question d'account.

Si je fais tourner mon service sur localUser -> il n'obtient pas les permissions de lecture/écriture sur le système de fichiers -> il ne sert à rien xD

Si je le fais tourner en localSystem -> il obtient les droits nécessaires (et même plus, ce qui n'est peut-être pas génial non plus) mais il tourne dans la session 0, réservée aux services (si j'ai bien compris l'idée). De fait, il n'a pas accès aux lecteurs réseaux montés sous un account user -> il ne sert encore à rien dans le contexte.

Je me suis donc dit "autant le faire tourner sur un account user" (en l'occurrence le mien )
Hum, sauf que je n'arrive pas à faire ça, le logger du service refuse mon account/pass. Je suppose que c'est logique d'ailleurs, le but n'est pas que le service soit moi, mais qu'il tourne dans mon contexte, ce qui doit se spécifier différemment.

J'ai fait pas mal de recherches sur le fonctionnement des services, mais les ressources en ligne sont généralement peu disertes sur le sujet des comptes, et très fréquemment out of date ( souvent relatives à XP, rarement à Vista, rien trouvé sur 7). La gestion de la sécurité ayant changé à chacune de ces versions, pas facile de trouver son bonheur...

Outch, désolé pour tout le baratin ^^'
Le contexte étant, je pense, suffisamment exposé, j'en viens (enfin :P) aux questions concrètes:

- Ne ferais-je pas mieux de porter la routine vers une application systray à démarrage auto ? (puisqu'elle dépend du log d'un user et du montage des lecteurs réseaux par ce même user)

Que la réponse à cette première question soit oui ou non, j'aimerais également savoir plusieurs choses (au cas où la problématique reviendrait dans d'autres contextes):

- Est-ce possible sous 7 de faire tourner un service dans le même contexte qu'un user loggé? (sans bloquer l'accès à l'user) Y compris un compte admin? (à éviter je suppose xD) Et si oui, comment?

- Le service sous LocalSystem peut-il exécuter programmatiquement des lignes de commandes de façon à monter les lecteurs réseaux dans son propre contexte? (dans ce cas l'utilisation du service regagnerait de l'intérêt, puisqu'il pourrait exécuter la routine sans user connecté).

- Savez-vous s'il existe quelque part une liste précise et exhaustive des privilèges accordés aux accounts LocalSystem et LocalUser sous 7, et pas comme dans la doc "minimal rights" et "many rights", ce qui ne renseigne pas beaucoup :/

En vous remerciant par avance pour vos réponses éclairées et éclairantes ^^

Il n'y a pas de docs précise pour les droits accordé à localUser et localSystem et localNetwork pour la simple et bonne raison que les credentials de ces comptes sont soumis aux règles de sécurité de l'entreprise, et donc du domaine dans lequel fonctionne la machine.
ces polices de sécurités sont définies partiellement par la configuration des polices locales et globales.

Pour ce qui est de ton problème, je ne suis pas convaincu qu'un service windows soit exactement ce dont tu as besoin. En effet, un service windows est une tâche de fond, qui s'accomplit en dehors de toute session, à quel qu'instant que ce soit, sur la machine. C'est donc parfait pour un Serveur SQL par exemple, mais un synchroniseur de données genre ActiveSync d'après ce que tu en dit... pas sure que ce soit pertinent, puisqu'il faut un accès à des comptes de personnes physiques pour que ca fonctionne ?

soit plus précis sur le vrai besoin, qu'est ce que tu synchronise au juste, ces lecteurs réseaux dépendent-ils des endusers (session) ou sont-ils toujours les mêmes quelque soient la session en cours ?

effectivement si ta problématique fait que les lecteurs en questions dépendent de la session et donc du user rattaché, le service windows n'est pas adapté.
de plus ces lecteurs réseaux... ce ne sont que des raccourcis vers une vraie adresse de services... pourquoi ne pas utiliser la véritable adresse plutôt que ces lecteurs réseaux ? et là ton service windows retrouvera tout son sens.
donne un exemple concret de ressource pointé par un lecteur réseau et de l'adresse qui est masquée par celui-ci.

sur mon poste de développeur par exemple j'ai un lecteur Z: qui pointe comme ceci
//gitfs/sources
tu l'aura compris... c'est un repository des sources des projets en plus d'être un serveur tfs. c'est bien un chemin réseau facile mais pourtant j'ai bien un lecteur réseau pointant dessus.

Merci pour ta réponse ^^

Effectivement, les lecteurs réseaux source sont de "simples" raccourcis vers une adresse sur un serveur(juste un "net use" dans un .bat), et le répertoire destination ne dépend pas de l'user connecté. C'est justement pour cette raison que je trouvais initialement le service adapté au contexte. (désolé, je pensais avoir été clair, mais en fait non ^^' )

Donc on peut connecter le service au serveur directement? (ça paraît logique 'fectivement ^^' ) Et vérifier que la connexion soit bien établie avant chaque traitement?

Si c'est le cas, ça résout d'un coup mon problème (et je n'ai plus qu'à aller me flageller pour ne pas y avoir pensé tout seul)

Ba a priori si ton service tourne avec les bons credentials (compte suffisamment privilégié) il peut aller directement sur les répertoires habituellement mappé sur tes lecteurs réseaux...

après tout l'assembly System.IO déborde de classes qui se fichent complètement de savoir si le chemin est local ou s'il est réseau (smb)
\\monserveur\dir...\fichier.ext

a priori si tu tourne dans un environnement Active Directory, il faut juste que la dite ressource réseau soit au moins accessible en lecture à tout le monde, ou alors non pas à un utilisateur, mais carrément accessible en lecture à la machine où tourne le service... dans un environnement AD il est tout à fait possible de configurer cela. Tu peux également attribué un compte spécifique AD à ton service si tu souhaite restreindre les accès de façon plus fine...

Même si un service utilise des privilèges pour s'exécuter, il n'interdit pas d'ouvrir une session avec le même login, et ne sera pas affecté par la fin de cette session. du moins c'est vrai sous windows vista, windows 7, et bien entendu sur les environnements serveurs comme Windows 2003 server ou 2008 server.
J'en suis pas entièrement sure sous XP car j'ai pas eu l'occasion de tester, mais à priori je dirais que c'est pareil.

Merci de nouveau ^^

Hum, ici la machine est considérée comme domaine enregistré auprès du serveur, mais l'accès au répertoire lui-même nécessite registration supplémentaire (le réseau est partagé par plusieurs groupes, chaque machine a accès au réseau et au serveur mais il faut donner les identifiants du groupe auquel on appartient pour accéder à certains répertoires).

Après, l'admin réseau (qui est tout seul) a préféré passer à chaque groupe un .bat qui mappe les dossiers qui le concerne plutôt que de paramétrer chaque machine individuellement (ce qui se comprend).

Mais il doit bien y avoir des fonctions en .net pour effectuer la connexion automatiquement... Au pire le service doit pouvoir exécuter le .bat voire lancer des commandes... Je vais bricoler et marquer le sujet comme résolu si j'arrive à quelque chose qui fonctionne.

[EDIT]: okay, en poussant le service à logguer ça session sur le partage ça fonctionne. Merci!