C # - Connecter un lecteur réseau à partir du service Web

Question

Nous travaillons sur un service Web qui doit exécuter un processus tiers qui interagit avec un lecteur réseau mappé. Nous devons donc mapper ce lecteur par programme à partir du service Web.

J'ai déjà terminé WNetAddConnection2, etc., dans une classe plus agréable pour un autre projet. J'ai donc inséré le code directement.

Notre service Web s'exécute sous UltiDev Cassini (au lieu d'IIS), qui s'exécute sous le compte Système. Nous obtenons le code d'erreur pour: " le nom de périphérique spécifié n'est pas valide " à chaque fois. J'ai également essayé d'emprunter l'identité d'autres utilisateurs dans le fichier web.config, avec les mêmes résultats.

Le lecteur mappera parfaitement lorsque j'exécuterai mon code à partir d'un programme de console sous un compte d'utilisateur normal.

J'ai également essayé d'exécuter l'équivalent "Net use". commande de C # avec exactement les mêmes résultats que WNetAddConnection.

Quelqu'un sait-il pourquoi un service Windows ou un utilisateur du système ne serait pas en mesure de mapper des lecteurs réseau?

Est-ce que quelqu'un connaît une solution de contournement? Mapper simplement le lecteur au démarrage du système serait une solution, mais comment l’utilisateur système / usurpé d’identité pourrait-il y accéder?

Lien pour UltiDev Cassini: UltiDev

SOLUTION: j'ai configuré le service UltiDev Cassini pour qu'il se connecte sous Administrateur et tout fonctionne correctement. L'emprunt d'identité ASP .Net ne doit pas fonctionner comme prévu.

Answer 1

Le compte LOCAL_SYSTEM présente une informations d'authentification sur le réseau . Vous pouvez utiliser un partage de réseau UNC pour accéder à ces informations, à condition qu'un utilisateur anonyme (Tout le monde) ait accès au partage.

Vous pouvez également installer Cassini en tant que service Windows que vous pouvez configurer. exécuter sous un autre utilisateur.

Answer 2

Si vous utilisez le compte Système local, j'estime qu'il est par nature incapable d'accéder au réseau [foo]. Je dirais que l'emprunt d'identité est votre seul chemin viable. Techniquement, vous pouvez réduire les contrôles d’accès sur le partage à un point tel que tout le monde peut lire / écrire sur le partage, mais cela pose plus de problèmes que de solutions.

Answer 3

Nous avons eu le même problème. Le problème se produit en raison du compte sous lequel le code est exécuté. Vous pouvez contourner ce problème comme nous l'avons fait en utilisant la classe suivante. Vous devez mapper le lecteur dans le même code que vous utilisez pour accéder / copier des fichiers. Le modèle que nous utilisons est de toujours vérifier si le lecteur est connecté en premier. Si tel est le cas, nous le déconnectons, puis nous le reconnectons. sinon, nous le connectons simplement. Il semble éclaircir le problème que vous décrivez.

public static class NetworkDrives
    {
        public static bool  MapDrive(string DriveLetter, string Path, string Username, string Password)
        {

            bool ReturnValue = false;

            if(System.IO.Directory.Exists(DriveLetter + ":\\"))
            {
                DisconnectDrive(DriveLetter);
            }
            System.Diagnostics.Process p = new System.Diagnostics.Process();
            p.StartInfo.UseShellExecute = false;
            p.StartInfo.CreateNoWindow = true;
            p.StartInfo.RedirectStandardError = true;
            p.StartInfo.RedirectStandardOutput = true;

            p.StartInfo.FileName = "net.exe";
            p.StartInfo.Arguments = " use " + DriveLetter + ": " + '"' + Path + '"' + " " + Password + " /user:" + Username;
            p.Start();
            p.WaitForExit();

            string ErrorMessage = p.StandardError.ReadToEnd();
            string OuputMessage = p.StandardOutput.ReadToEnd();
            if (ErrorMessage.Length > 0)
            {
                throw new Exception("Error:" + ErrorMessage);
            }
            else
            {
                ReturnValue = true;
            }
            return ReturnValue;
        }
        public static bool DisconnectDrive(string DriveLetter)
        {
            bool ReturnValue = false;
            System.Diagnostics.Process p = new System.Diagnostics.Process();
            p.StartInfo.UseShellExecute = false;
            p.StartInfo.CreateNoWindow = true;
            p.StartInfo.RedirectStandardError = true;
            p.StartInfo.RedirectStandardOutput = true;

            p.StartInfo.FileName = "net.exe";
            p.StartInfo.Arguments = " use " + DriveLetter + ": /DELETE";
            p.Start();
            p.WaitForExit();

            string ErrorMessage = p.StandardError.ReadToEnd();
            string OuputMessage = p.StandardOutput.ReadToEnd();
            if (ErrorMessage.Length > 0)
            {
                throw new Exception("Error:" + ErrorMessage);
            }
            else
            {
                ReturnValue = true;
            }
            return ReturnValue;
        }

    }

Answer 4

Au lieu d’un lecteur mappé, pourriez-vous vous connecter en utilisant le partage UNC?

J'emprunterais toujours l'identité d'un utilisateur ayant accès au partage.

Answer 5

Je l’ai déjà fait auparavant, mais cela fait très longtemps - comme en 1997 et Win NT 3.51 avec Delphi 2

Je cours de mémoire, mais je pense que cela ressemble à ceci: Vous utilisez l'API Win:

WNetAddConnection2 ()

Informations sur l'appel: http: // msdn .microsoft.com / fr-us / library / aa385413 (VS.85) .aspx

Vous pouvez obtenir la signature c # auprès de pInvoke.net: http: // www.pinvoke.net/default.aspx/mpr/WNetAddConnection2.html

Note sur la configuration: Je pense que vous devrez configurer un compte de domaine pour le service et exécuter le service avec l'identité de ce compte au lieu du système local. Je pense que vous passez null comme nom d'utilisateur et mot de passe.

Vous pourriez pouvoir exécuter le service en tant que système local transmettez le nom d'utilisateur et le mot de passe d'un compte de domaine. Je ne sais pas si le compte système est autorisé à accéder au réseau. / p>

Answer 6

Le concept général à garder à l’esprit est que les «lettres de lecteur mappées» sont un concept d’utilisateur, pas un concept de système. Ainsi, lorsque Joe se connecte à l'ordinateur Windows, les lecteurs mappés sont attachés au compte d'utilisateur Joe. Lorsqu'un service Windows est en cours d'exécution, il s'exécute généralement sous le "compte d'utilisateur" LOCAL_SYSTEM, ce qui signifie que LOCAL_SYSTEM ne connaît pas les lettres de lecteur mappées de Joe.

Par conséquent, l'accès UNC aux partages réseau constitue le meilleur moyen d'accéder à une ressource distante à partir d'un service Windows. Notez que vous pouvez exécuter le service Windows dans le contexte du compte utilisateur "Joe", ou créer un compte AD factice appelé quelque chose comme "MyServiceAccount" et attribuer les droits de ce compte à l'UNC, ou bien utiliser l'emprunt d'identité et le Le service Windows se connecte au poste de travail local à l'aide de la fonction NetLogon () avec un descripteur d'emprunt d'identité, puis accède à l'UNC à partir de là.

Il existe de nombreuses façons de le faire, mais tous les comptes d'utilisateur sont associés aux lecteurs mappés et à l'accès UNC.

Bonne chance, espérons que cette information vous aide!