C # - Mappa unità di rete dal servizio Web

Question

Stiamo lavorando su un servizio Web che deve eseguire un processo di terze parti che interagisce con un'unità di rete mappata. Quindi dobbiamo mappare questo disco programmaticamente dal servizio web.

Ho già inserito WNetAddConnection2, ecc. in una classe migliore per un altro progetto, quindi ho inserito il codice.

Il nostro servizio Web è in esecuzione sotto UltiDev Cassini (anziché IIS) che viene eseguito con l'account di sistema. Otteniamo il codice di errore per: "il nome del dispositivo specificato non è valido" ogni volta. Ho anche provato a impersonare altri utenti nel file web.config, con gli stessi risultati.

L'unità verrà mappata correttamente quando eseguo il mio codice da un programma della console con un normale account utente.

Ho anche provato a eseguire l'equivalente " net use " comando da C # con gli stessi esatti risultati di WNetAddConnection.

Qualcuno sa perché un servizio Windows o un utente di sistema non sarebbero in grado di mappare le unità di rete?

Qualcuno conosce una soluzione alternativa? Mappare semplicemente l'unità all'avvio del sistema sarebbe una soluzione, ma come potrebbe accedervi il sistema / utente rappresentato?

Link per UltiDev Cassini: UltiDev

SOLUZIONE: ho impostato il servizio UltiDev Cassini per accedere sotto Amministratore e tutto funziona. La rappresentazione ASP .Net non deve funzionare come previsto.

Answer 1

L'account LOCAL_SYSTEM presenta le credenziali anonime sulla rete . È possibile utilizzare una condivisione di rete UNC per accedere a queste informazioni, a condizione che l'anonimo (Everyone) abbia accesso alla condivisione.

Puoi anche installare Cassini come servizio Windows che puoi configurare per essere eseguito con un altro utente.

Answer 2

Se stai utilizzando l'account di sistema locale, credo che sia intrinsecamente incapace di accedere alla rete [pippo]. Direi che la rappresentazione è il tuo unico percorso percorribile. Tecnicamente potresti ridurre i controlli di accesso sulla condivisione al punto che chiunque potrebbe leggere / scrivere sulla condivisione, ma ciò comporta più problemi che soluzioni.

Answer 3

Abbiamo avuto lo stesso problema. Il problema si verifica a causa dell'account con cui è in esecuzione il codice. Puoi aggirare questo come abbiamo fatto usando la seguente classe. Devi mappare l'unità con lo stesso codice che stai utilizzando per accedere / copiare i file. Il modello che utilizziamo è di verificare sempre se l'unità è connessa per prima. in tal caso, lo disconnettiamo e quindi lo riconnettiamo. in caso contrario, lo colleghiamo semplicemente. Sembra chiarire il problema che stai descrivendo.

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

Invece di un'unità mappata, potresti connetterti utilizzando la condivisione UNC?

Imiterei ancora un utente che ha accesso alla condivisione.

Answer 5

L'ho già fatto prima, ma è stato MOLTO tempo fa - come il 1997, e Win NT 3.51 con Delphi 2

Sto correndo dalla memoria, ma penso che vada qualcosa del genere: Si utilizza l'API Win:

WNetAddConnection2 ()

Informazioni sulla chiamata: http: // msdn .microsoft.com / en-us / library / aa385413 (VS.85) aspx

Puoi ottenere la firma c # da pInvoke.net: http: // www.pinvoke.net/default.aspx/mpr/WNetAddConnection2.html

Nota sulla configurazione: Penso che sarà necessario impostare un account di dominio per il servizio ed eseguire il servizio con l'identità di tale account anziché il sistema locale. Penso che passi null come nome utente e password.

potresti essere in grado di eseguire il servizio poiché il sistema locale passa il nome utente e la password di un account di dominio - non so se all'account di sistema sia consentito l'accesso alla rete.

Answer 6

Il concetto generale da tenere presente è che le "lettere di unità mappate" sono un concetto utente, non un concetto di sistema. Pertanto, quando Joe accede al computer Windows, le unità mappate vengono collegate all'account utente Joe. Quando un servizio Windows è in esecuzione, generalmente è in esecuzione sotto l'account utente LOCAL_SYSTEM, il che significa che LOCAL_SYSTEM non è a conoscenza delle lettere di unità mappate di Joe.

Pertanto, l'accesso UNC alle condivisioni di rete è la strada da percorrere quando si tenta di accedere a qualsiasi risorsa remota da un servizio Windows. Si noti che è possibile eseguire il servizio Windows nel contesto dell'account utente "Joe" oppure creare un account AD fittizio denominato "MyServiceAccount" e assegnare tali diritti all'UNC oppure utilizzare Impersonation e disporre di Il servizio Windows accede alla workstation locale usando la funzione NetLogon () con un handle di rappresentazione e quindi accede a UNC da lì.

Esistono molti modi per farlo, ma tutti gli account utente sono associati a unità mappate e accesso UNC.

Buona fortuna, spero che queste informazioni siano utili!