Supporto per la denominazione UNC e MUP

Questo articolo descrive come un redirector di rete può supportare la denominazione UNC e il provider UNC (MUP).

MUP è un servizio Windows che consente di individuare le risorse di rete identificate tramite UNC (convenzione di denominazione uniforme). Si tratta di un componente in modalità kernel responsabile del canale di tutti gli accessi al file system remoto usando un nome UNC a un redirector di rete (provider UNC) in grado di gestire le richieste del file system remoto. MUP è coinvolto quando un'applicazione usa un percorso UNC; Ad esempio, un comando della riga di comando, ad esempio:

notepad \\server\public\readme.txt

MUP riceve comandi contenenti nomi UNC dalle applicazioni. Invia il nome a ogni provider UNC registrato, alla workstation LAN Manager e a tutti gli altri installati. Quando un provider UNC identifica un nome UNC come proprio, MUP reindirizza automaticamente le istanze future di tale nome a tale provider.

MUP non è coinvolto durante un'operazione che crea una lettera di unità mappata ,ad esempio il comando "NET USE". Questa operazione viene gestita da più router provider (MPR) e da una DLL del provider di rete Windows (WNet) in modalità utente per il reindirizzamento di rete. Tuttavia, una DLL del provider WNet in modalità utente può comunicare direttamente con un driver del redirector di rete in modalità kernel durante questa operazione.

Prima di Windows Vista, le operazioni remote sui file eseguite su un'unità mappata che non rappresentano un'unità DFS (Distributed File System) non passano attraverso MUP. Queste operazioni passano direttamente al provider di rete che ha gestito il mapping delle lettere di unità.

Per i reindirizzamenti di rete conformi al modello di reindirizzamento aggiornato introdotto in Windows Vista, MUP è coinvolto anche quando viene usata un'unità di rete mappata. Le operazioni sui file eseguite nell'unità mappata passano attraverso MUP al reindirizzamento di rete. In questo caso, MUP passa semplicemente l'operazione al redirector di rete coinvolto.

MUP fa parte del file binario mup.sys , che include anche il client DFS (Distributed File System).

Un redirector di rete kernel ha in genere anche una DLL del provider WNet in modalità utente per supportare la creazione di connessioni alle risorse remote ,ad esempio il mapping delle lettere di unità alle risorse remote. MPR è una DLL in modalità utente che stabilisce connessioni di rete basate su query a provider di reti WNet. Le chiamate a MPR derivano da una delle operazioni seguenti:

• Comando net use x: \\server\share emesso da un prompt dei comandi.

• Connessione di lettera di unità di rete stabilita da Esplora risorse.

• Chiamate dirette alle funzioni WNet.

Un redirector di rete deve registrarsi con MUP per gestire i nomi UNC. È possibile registrare più provider UNC con MUP. Questi provider UNC possono essere uno o più dei seguenti redirector:

• Mini-reindirizzamenti di rete basati su RDBSS, ad esempio il redirector SMB (Server Message Block) e il redirector WebDAV.
• I reindirizzamenti legacy non basati su SERVIZI Desktop remoto.

Risoluzione del prefisso

MUP determina quale provider può gestire un percorso UNC in un'operazione basata sul nome, in genere una richiesta IRP_MJ_CREATE. Questa determinazione viene definita "risoluzione del prefisso". L'operazione di risoluzione del prefisso serve due scopi:

• L'operazione basata sul nome che ha generato la risoluzione del prefisso viene instradata al provider che dichiara il prefisso. In caso di esito positivo, MUP garantisce che le operazioni successive basate su handle (IRP_MJ_READ e IRP_MJ_WRITE, ad esempio) vadano allo stesso provider ignorando completamente MUP.

• Il provider e il relativo prefisso richiesto vengono immessi in una cache dei prefissi gestita da MUP. Per le operazioni successive basate sui nomi, MUP usa questa cache dei prefissi per determinare se un provider ha già richiesto un prefisso prima di tentare di eseguire una risoluzione del prefisso. Ogni voce in questa cache dei prefissi è soggetta a un timeout (detto TTL) dopo l'aggiunta alla cache. Una voce viene generata dopo la scadenza di questo timeout, in cui MUP esegue nuovamente la risoluzione del prefisso per questo prefisso in un'operazione successiva basata sul nome.

MUP esegue la risoluzione dei prefissi inviando una richiesta di IOCTL_REDIR_QUERY_PATH ai reindirizzamenti di rete registrati con MUP. I buffer di input e di output per IOCTL_REDIR_QUERY_PATH vengono allocati da un pool non di paging.

I reindirizzamenti di rete devono consentire solo i mittenti in modalità kernel di questo IOCTL, verificando che il membro RequesterMode della struttura IRP sia KernelMode.

MUP usa la struttura QUERY_PATH_REQUEST per le informazioni sulla richiesta.

I provider UNC devono usare la struttura QUERY_PATH_RESPONSE per le informazioni sulla risposta.

Qualsiasi redirector di rete legacy (non basato sull'uso di RDBSS) che viene registrato come provider UNC con MUP chiamando FsRtlRegisterUncProvider riceve la richiesta di IOCTL_REDIR_QUERY_PATH.

Un mini-redirector di rete che indica il supporto come provider UNC riceve questa attestazione di prefisso come se fosse una chiamata IRP_MJ_CREATE. Questa richiesta di creazione è simile a una chiamata CreateFile in modalità utente con FILE_CREATE_TREE_CONNECTION flag impostato su . Un mini-redirector di rete non riceve l'attestazione di prefisso come chiamata a MRxLowIOSubmit[LOWIO_OP_IOCTL]. Per un'attestazione di prefisso, RDBSS invia una richiesta MRxCreateSrvCall al mini-redirector di rete seguito da una chiamata a MRxSrvCallWinnerNotify e MRxCreateVNetRoot. Quando un mini-reindirizzamento di rete viene registrato con RDBSS, RDBSS copia la tabella dispatch driver per il mini-redirector di rete in modo da puntare ai punti di ingresso interni di SERVIZI Desktop remoto. RDBSS riceve quindi questa IOCTL_REDIR_QUERY_PATH internamente per il mini-redirector di rete e chiama MRxCreateSrvCall, MRxSrvCallWinnerNotify e MRxCreateVNetRoot. La IOCTL_REDIR_QUERY_PATH IRP originale è contenuta nella struttura RX_CONTEXT passata alla routine MRxCreateSrvCall. Inoltre, i membri seguenti nella RX_CONTEXT passati a MRxCreateSrvCall vengono modificati:

• Il membro MajorFunction è impostato su IRP_MJ_CREATE anche se l'IRP originale è stato IRP_MJ_DEVICE_CONTROL.
• Il membro PrefixClaim.SuppliedPathName.Buffer è impostato sul membro FilePathName della struttura QUERY_PATH_REQUEST.
• Il membro PrefixClaim.SuppliedPathName.Length è impostato sul membro PathNameLength della struttura QUERY_PATH_REQUEST.
• Il membro Create.NtCreateParameters.SecurityContext è impostato sul membro SecurityContext della struttura QUERY_PATH_REQUEST.
• Il membro Create.ThisIsATreeConnectOpen è impostato su TRUE.
• Il membro Create.Flags ha il RX_CONTEXT_CREATE_FLAG_UNC_NAME bit impostato.

Se il mini-redirector di rete vuole visualizzare i dettagli dell'attestazione del prefisso, può leggere questi membri nel RX_CONTEXT passato a MRxCreateSrvCall. In caso contrario, può solo tentare di connettersi alla condivisione server e restituire STATUS_SUCCESS se la chiamata MRxCreateSrvCall ha avuto esito positivo. RDBSS effettua l'attestazione di prefisso per conto del mini-redirector di rete.

C'è un caso in cui un mini-redirector di rete potrebbe ricevere direttamente questo IOCTL. Un mini-reindirizzamento di rete potrebbe salvare una copia della tabella dispatch del driver prima di inizializzare e registrare con RDBSS. Dopo aver chiamato RxRegisterMinirdr per eseguire la registrazione con RDBSS, il mini-redirector di rete potrebbe salvare una copia dei nuovi punti di ingresso della tabella dispatch driver installati da RDBSS e ripristinare la tabella di invio del driver originale. La tabella dispatch del driver ripristinata deve essere modificata in modo che dopo aver controllato l'IRP ricevuto per i provider di integrazione interessati al mini-reindirizzamento di rete, la chiamata viene inoltrata ai punti di ingresso del driver RDBSS. RDBSS copia la tabella dispatch del driver di un mini-redirector di rete quando il driver inizializza RDBSS e chiama RxRegisterMinrdr. Un mini-reindirizzamento di rete che si collega a rdbsslib.lib deve salvare la tabella di invio del driver originale prima di chiamare RxDriverEntry dalla routine DriverEntry per inizializzare la libreria statica RDBSS e ripristinare la tabella dispatch del driver dopo aver chiamato RxRegisterMinrdr. Questo requisito è dovuto al fatto che RDBSS copia la tabella dispatch del mini-redirector di rete nelle routine RxDriverEntry e RxRegisterMinrdr .

Il valore del Registro di sistema providerOrder REG_SZ controlla l'ordine in cui i provider vengono sottoposti a query durante la risoluzione del prefisso. Questo valore viene archiviato nella chiave seguente:

HKLM\System\CurrentControlSet\Control\NetworkProvider\Order

I nomi dei singoli provider nel valore del Registro di sistema ProviderOrder sono separati da virgole senza spazi vuoti iniziali o finali.

Ad esempio, questo valore può contenere la stringa:

RDPNP,LanmanWorkstation,WebClient

Dato un percorso UNC \\<server>\<share>\<path>, MUP emette una richiesta di risoluzione del prefisso se il prefisso (\\server\share o \\server, ad esempio) non viene trovato nella cache dei prefissi MUP. MUP invia una richiesta di risoluzione del prefisso a ogni provider nell'ordine seguente fino a quando un provider non richiede il prefisso o fino a quando non viene eseguita una query su tutti i provider:

1. Client TS (RDPNP)

2. Redirector SMB (LanmanWorkstation)

3. Redirector WebDAV (WebClient)

Le modifiche apportate al valore del Registro di sistema ProviderOrder richiedono un riavvio per rendere effettivo MUP.

MUP usa ogni nome del provider elencato per trovare la chiave del Registro di sistema del provider nella chiave del Registro di sistema seguente:

HKLM\System\CurrentControlSet\Services\<ProviderName>

MUP legge quindi il valore DeviceName nella sottochiave NetworkProvider per trovare il nome del dispositivo con cui verrà registrato il provider. Quando il provider esegue effettivamente la registrazione, MUP corrisponde al nome del dispositivo passato con l'elenco dei nomi dei dispositivi di provider noti. Inserisce quindi il provider in un elenco ordinato ai fini della risoluzione del prefisso. L'ordine dei provider in questo elenco è basato sull'ordine specificato nel valore del Registro di sistema ProviderOrder descritto in precedenza.

Il router a più provider (MPR), la DLL in modalità utente che stabilisce le connessioni di rete in base alle query ai provider WNet, rispetta anche questo ordine del provider.

MUP rilascia la richiesta di risoluzione del prefisso in modo seriale e si arresta non appena il primo provider richiede il prefisso. Pertanto, nell'esempio precedente, se RDPNP richiede un prefisso, MUP non chiama i redirector SMB o WebDAV.

"Risoluzione del prefisso seriale" (rispetto a parallel) impedisce a un redirector di rete con priorità providerOrder inferiore di causare problemi di prestazioni per un redirector di rete con priorità providerOrder superiore. Si consideri, ad esempio, un server remoto, con un firewall configurato per bloccare determinati tipi di pacchetti TCP/IP ,ad esempio l'accesso a HTTP, ma per consentire ad altri utenti (ad esempio, l'accesso SMB). In questo caso, anche se il redirector di rete SMB è configurato come primo provider nel valore ProviderOrder e richiede rapidamente il prefisso, il reindirizzamento WebDAV potrebbe ritardare significativamente il completamento della risoluzione del prefisso attendendo il timeout della connessione TCP.