J'ai un EXE C # qui doit être exécuté à l'aide de WMI et accéder à une part de réseau. Cependant, lorsque j'accède à la part, je reçois une inscription non autorisée. Si j'exécute l'EXE directement, la part est accessible. J'utilise le même compte d'utilisateur dans les deux cas.
Il y a deux parties à mon application, un client d'interface graphique exécutant sur un PC local et un processus de backend qui fonctionne sur un PC distant. Lorsque le client doit se connecter au backend, il lance d'abord le processus distant à l'aide de WMI (code reproduit ci-dessous). Le processus distant fait un certain nombre de choses, notamment accéder à un partage réseau à l'aide de Directory.GetDirectories () et rapporte au client. P>
Lorsque le processus distant est lancé automatiquement par le client à l'aide du WMI, il ne peut pas accéder à la Partager réseau. Toutefois, si je me connecte à la machine distante à l'aide du bureau distant et lancez manuellement le processus de backend, l'accès à la part du réseau réussit. P>
L'utilisateur spécifié dans l'appel WMI et l'utilisateur connecté pour la session de bureau à distance sont les mêmes, afin que les autorisations soient les mêmes, ne devraient-ils pas? P>
Je vois dans l'entrée MSDN pour répertoire.exists () indique" la méthode existante n'effectue pas l'authentification du réseau. Si vous interrogez une part de réseau existant sans être pré- authentifié, la méthode existante reviendra fausse. " Je suppose que cela est lié? Comment puis-je vous assurer que l'utilisateur est authentifié correctement dans une session WMI? P>
ConnectionOptions opts = new ConnectionOptions(); opts.Username = username; opts.Password = password; ManagementPath path = new ManagementPath(string.Format("\\\\{0}\\root\\cimv2:Win32_Process", remoteHost)); ManagementScope scope = new ManagementScope(path, opts); scope.Connect(); ObjectGetOptions getOpts = new ObjectGetOptions(); using (ManagementClass mngClass = new ManagementClass(scope, path, getOpts)) { ManagementBaseObject inParams = mngClass.GetMethodParameters("Create"); inParams["CommandLine"] = commandLine; ManagementBaseObject outParams = mngClass.InvokeMethod("Create", inParams, null); }
4 Réponses :
Après avoir suivi le lien suggéré par Isalamon ci-dessus (merci) J'ai suivi les conseils de Jestro et j'ai réécrit avec Psexec.exe (qui peut être téléchargé à partir de http://technet.microsoft.com/en-us/sysinternals/bb897553.aspx ) au lieu de WMI. Cela ressemble à un peu de kludge de le faire de cette façon, mais il semble fonctionner.
Nouveau code pour quiconque rencontre des problèmes similaires: p>
WMI utilise simplement l'impersonnation lors de l'exécution du processus distant, qui ne vous donne pas accès au réseau. Si vous allez bien sortir du code géré, vous pouvez simplement mapper un chemin UNC dans le processus distant WMI commencée à utiliser les informations d'identification souhaitées. Ensuite, vous avez l'accès réseau que vous voulez. J'utilise NetouseAdd et Netusedel de NetAPI32.dll pour mapper le chemin UNC. Voir http://pinvoke.net/ pour plus de détails sur l'utilisation des API. P>
Vous pouvez écrire toutes vos commandes au fichier batch à la machine distante qui inclut une utilisation nette (aucune lettre de lecteur) pour faire une authentification. Fonctionne bien de cette façon. Je travaille toujours sur une alternative. P>
En fait, si vous faites quelque chose comme ceci, cela fonctionnera également, je viens de le tester:
Oups ici c'est: inparams ["Commandline"] = "cmd / c \" "+" user net \\\\ serveur \\ C $ mot de passe / utilisateur: domaine \\ nom d'utilisateur && <\\ serveur \ Partager \ PLUS. BAT> "+" \ "> c: \\ temp \\ r_output.txt"; Je le connecte pour récupérer la sortie plus tard dans mon code. Dans ce cas, il enregistre l'exécution du fichier de commandes, pas de commandes.
Je sais que vous l'avez triplé à l'aide de PSEXEC, qui est un programme fantastique, mais si vous vouliez revenir à WMI, avez-vous essayé de permettre la suivante dans vos collègues: p>
Quel est ce qui suit: p>
Obtient ou définit une valeur indiquant si les privilèges d'utilisateurs doivent être activé pour l'opération de connexion. Cette propriété ne devrait être que utilisé lorsque l'opération effectuée nécessite un certain privilège d'utilisateur pour être activé (par exemple, un redémarrage de la machine). p> blockQuote>
http://msdn.microsoft.com /en-us/library/system.management.connectionOptionS.enableprivileges.aspx P> blockQuote>
Obtient ou définit le niveau d'impersonnation COM à utiliser pour des opérations à cette connexion. P> blockQuote>
http://msdn.microsoft.com /en-us/library/system.management.connectionOptionS.impersonation.aspx P> blockQuote>
Je pense qu'ils devraient dire à votre WMI de permettre au programme d'avoir les informations d'identification correctes et d'accéder ainsi à votre part de réseau p>
Je viens de tester que dans une application, j'ai écrit pour accéder à une base de données sur le réseau, et cela ne peut pas y accéder si je le lance à distance avec WMI et ces options de connexion, mais cela fonctionne si je lance l'application directement connectée à la machine distante. . Vous penseriez que cela donnerait accès.
problème similaire Stackoverflow.com/Questtions/2291921/...
Merci, ma recherche n'avait pas montré ça. Je vais avoir une lecture et voir si cela aide.
J'ai ajouté l'utilisateur et donné des permanentes complètes, mais cela ne fait aucune différence :(
Y a-t-il une solution sans dépend (nécessitant un déploiement de) programme tiers comme Psexec?