11
votes

Authentification réseau lors de l'exécution d'EXE de WMI

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 commentaires

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?


4 Réponses :


2
votes

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: xxx


0 commentaires

2
votes

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.


0 commentaires

0
votes

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.


2 commentaires

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.



1
votes

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:


1 commentaires

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.