Unterstützung für UNC-Benennung und MUP

In diesem Artikel wird beschrieben, wie ein Netzwerk-Redirector die Benennung gemäß einheitlicher Benennungskonvention (Uniform Naming Convention, UNC) und den MUP (Multiple UNC Provider) unterstützen kann.

MUP ist eine vom System bereitgestellte Kernelmoduskomponente, die für den Umgang mit UNC-Pfaden verantwortlich ist:

• Sie hilft beim Auffinden von Netzwerkressourcen, die UNC verwenden.

• Sie leitet alle Remotedateisystemzugriffe mithilfe eines UNC-Namens zu einem Netzwerk-Redirector, der die Remote-Dateisystemanforderungen verarbeiten kann. Der Netzwerk-Redirector ist der UNC-Anbieter.

MUP ist beteiligt, wenn eine Anwendung einen UNC-Pfad verwendet; Beispiel: ein Befehlszeilenbefehl wie:

notepad \\server\public\readme.txt

MUP empfängt Befehle mit UNC-Namen von Anwendungen. Es sendet den Namen an jeden registrierten UNC-Anbieter und alle anderen installierten Netzwerkanbieter. Wenn ein UNC-Anbieter einen UNC-Namen als seinen eigene identifiziert, leitet MUP automatisch zukünftige Instanzen dieses Namens an diesen Anbieter weiter.

MUP ist an einem Vorgang, der einen zugeordneten Laufwerksbuchstaben erstellt (z. B. der Befehl „NET USE“), nicht beteiligt. Stattdessen bearbeiten der MPR (Multiple Provider R) und ein Benutzermodus-Windows Networking (WNet)-Anbieter-DL diesen Vorgang für den Netzwerk-Redirector. Allerdings kann eine WNet-Provider-DLL im Benutzermodus während dieses Vorgangs direkt mit einem Netzwerk-Redirector-Treiber im Kernelmodus kommunizieren.

Bei Netzwerk-Redirectors, die dem Redirector-Modell ab Windows Vista entsprechen, ist MUP beteiligt, selbst wenn ein zugeordnetes Netzwerklaufwerk verwendet wird. Dateivorgänge, die auf dem zugeordneten Laufwerk ausgeführt werden, durchlaufen den MUP zum Netzwerk-Redirector. In diesem Fall übergibt MUP einfach den Vorgang an den beteiligten Netzwerk-Redirector.

MUP ist Teil der mup.sys-Binärdatei, die auch den DFS (Distributed File System)-Client enthält.

Ein Kernel-Netzwerk-Redirector verfügt normalerweise auch über eine WNet-Provider-DLL für den Benutzermodus, um das Herstellen von Verbindungen mit Remoteressourcen zu unterstützen (z. B. Zuordnen von Laufwerkbuchstaben zu Remoteressourcen). Der MPR ist eine Benutzermodus-DLL, die Netzwerkverbindungen basierend auf Abfragen an WNet-Provider herstellt. Aufrufe an den MPR resultieren aus einem der folgenden Vorgänge:

• Ein von einer Eingabeaufforderung ausgegebener net use x: \\server\share-Befehl.

• Eine über den Windows Explorer hergestellte Verbindung zum Netzwerklaufwerksbuchstaben.

• Direkte Aufrufe von WNet-Funktionen.

Ein Netzwerk-Redirector muss sich beim MUP registrieren, um UNC-Namen zu verarbeiten. Beim MUP können mehrere UNC-Provider registriert sein. Bei diesen UNC-Providern kann es sich um einen oder mehrere der folgenden Redirectors handeln:

• Netzwerk-Mini-Redirectors basierend auf RDBSS, z. B. Server Message Block (SMB)-Redirector und WebDAV-Redirector.
• Ältere Redirectors, die nicht auf RDBSS basieren.

Präfixauflösung

Der MUP bestimmt, welcher Provider einen UNC-Pfad in einem namensbasierten Vorgang verarbeiten kann, in der Regel eine IRP_MJ_CREATE-Anforderung. Dies wird als „Präfixauflösung“ bezeichnet. Der Präfixauflösungsvorgang dient zwei Zwecken:

• Der namensbasierte Vorgang, der zu der Präfixauflösung führte, wird an den Provider weitergeleitet, der das Präfix beansprucht. Bei Erfolg stellt der MUP sicher, dass nachfolgende Handle-basierte Vorgänge (z. B. IRP_MJ_READ und IRP_MJ_WRITE) an denselben Provider gehen und den MUP vollständig umgehen.

• Der Provider und das von ihm beanspruchte Präfix werden in einen von MUP verwalteten Präfix-Cache eingetragen. Bei nachfolgenden namenbasierten Vorgängen verwendet der MUP diesen Präfix-Cache, um zu bestimmen, ob ein Provider bereits ein Präfix beansprucht hat, bevor versucht wird, eine Präfixauflösung auszuführen. Jeder Eintrag in diesem Präfix-Cache unterliegt einem Timeout (als TTL bezeichnet), sobald er dem Cache hinzugefügt wird. Nach Ablauf dieser Zeitüberschreitung wird ein Eintrag verworfen. Zu diesem Zeitpunkt führt MUP bei einem nachfolgenden namensbasierten Vorgang erneut eine Präfixauflösung für dieses Präfix durch.

Der MUP führt eine Präfixauflösung durch Ausstellen einer IOCTL_REDIR_QUERY_PATH-Anforderung an Netzwerk-Redirector aus, die beim MUP registriert sind. Die Eingabe- und Ausgabepuffer für IOCTL_REDIR_QUERY_PATH werden aus einem Pool ohne Paging zugewiesen.

Netzwerk-Redirector sollten nur Kernelmodus-Absender dieses IOCTL zulassen, indem überprüft wird, ob das RequesterMode-Element der IRP-Struktur KernelMode ist.

MUP verwendet die QUERY_PATH_REQUEST-Struktur für die Anforderungsinformationen.

UNC-Provider sollten die QUERY_PATH_RESPONSE-Struktur für die Antwortinformationen verwenden.

Alle älteren Netzwerk-Redirectors (nicht basierend auf der Verwendung von RDBSS), die sich als UNC-Provider beim MUP registrieren, indem sie FsRtlRegisterUncProvider aufrufen, erhalten die IOCTL_REDIR_QUERY_PATH-Anforderung.

Ein Netzwerk-Mini-Redirector, der Unterstützung als UNC-Provider angibt, erhält diesen Präfixanspruch, als wäre es ein IRP_MJ_CREATE-Aufruf. Diese Anforderung zum Erstellen ähnelt einem CreateFile-Aufruf im Benutzermodus, wobei das FILE_CREATE_TREE_CONNECTION-Flag aktiviert ist. Ein Netzwerk-Mini-Redirector empfängt den Präfixanspruch nicht als Aufruf von MRxLowIOSubmit[LOWIO_OP_IOCTL]. Für einen Präfixanspruch sendet RDBSS eine MRxCreateSrvCall-Anforderung an den Netzwerk-Mini-Redirector, gefolgt von einem Aufruf von MRxSrvCallWinnerNotify und MRxCreateVNetRoot. Wenn sich ein Netzwerk-Mini-Redirector bei RDBSS registriert, kopiert RDBSS die Treiber-Dispatchtabelle für den Netzwerk-Mini-Redirector, um auf interne RDBSS-Einstiegspunkte zu verweisen. RDBSS empfängt dann diesen IOCTL_REDIR_QUERY_PATH intern für den Netzwerk-Mini-Redirector und ruft MRxCreateSrvCall, MRxSrvCallWinnerNotify und MRxCreateVNetRoot auf. Das ursprüngliche IOCTL_REDIR_QUERY_PATH-IRP ist in der RX_CONTEXT-Struktur enthalten, die an die MRxCreateSrvCall-Routine übergeben wird. Darüber hinaus werden die folgenden Elemente im RX_CONTEXT, die an MRxCreateSrvCall übergeben werden, geändert:

• Das MajorFunction-Element ist auf IRP_MJ_CREATE festgelegt, obwohl das ursprüngliche IRP IRP_MJ_DEVICE_CONTROL war.
• Das PrefixClaim.SuppliedPathName.Buffer-Element ist auf das FilePathName-Element der QUERY_PATH_REQUEST-Struktur festgelegt.
• Das PrefixClaim.SuppliedPathName.Length-Element ist auf das PathNameLength-Element der QUERY_PATH_REQUEST-Struktur festgelegt.
• Das Create.NtCreateParameters.SecurityContext-Element ist auf das SecurityContext-Element der QUERY_PATH_REQUEST-Struktur festgelegt.
• Das Create.ThisIsATreeConnectOpen-Mitglied wird auf TRUE gesetzt.
• Das Create.Flags-Element verfügt über den RX_CONTEXT_CREATE_FLAG_UNC_NAME-Bitsatz.

Wenn der Netzwerk-Redirector Details des Präfixanspruchs anzeigen möchte, kann er diese Elemente in RX_CONTEXT lesen, die an MRxCreateSrvCall übergeben werden. Andernfalls kann nur versucht werden, eine Verbindung mit der Serverfreigabe herzustellen und STATUS_SUCCESS zurückzugeben, wenn der MRxCreateSrvCall-Aufruf erfolgreich war. RDBSS macht den Präfixanspruch im Namen des Netzwerk-Mini-Redirectors geltend.

Es gibt einen Fall, in dem ein Netzwerk-Mini-Redirector diese IOCTL direkt empfangen könnte. Ein Netzwerk-Mini-Redirector könnte eine Kopie seiner Treiber-Dispatchtabelle speichern, bevor er RDBSS initialisiert und registriert. Nach dem Aufruf von RxRegisterMinirdr zur Registrierung bei RDBSS könnte der Netzwerk-Mini-Redirector eine Kopie der neuen, von RDBSS installierten Einstiegspunkte der Treiber-Dispatchtabellen speichern und seine ursprüngliche Treiber-Dispatchtabelle wiederherstellen. Die wiederhergestellte Treiber-Dispatchtabelle müsste so geändert werden, dass nach der Überprüfung des empfangenen IRP für diejenigen, die für den Netzwerk-Mini-Redirector von Interesse sind, der Aufruf an die RDBSS-Treiber-Dispatch-Einstiegspunkte weitergeleitet wird. RDBSS kopiert die Treiber-Dispatchtabelle eines Netzwerk-Mini-Redirectors, wenn der Treiber RDBSS initialisiert und RxRegisterMinrdr aufruft. Ein Netzwerk-Mini-Redirector, der eine Verbindung zu rdbsslib.lib herstellt, muss seine ursprüngliche Treiber-Dispatchtabelle speichern, bevor er RxDriverEntry aus seiner DriverEntry-Routine aufruft, um die statische RDBSS-Bibliothek zu initialisieren und seine Treiber-Dispatchtabelle nach dem Aufruf von RxRegisterMinrdr wiederherzustellen. Das liegt daran, dass RDBSS über die Dispatchtabelle des Netzwerk-Mini-Redirectors in den RxDriverEntry- und RxRegisterMinrdr-Routinen kopiert wird.

Der Registrierungswert REG_SZ ProviderOrder steuert die Reihenfolge, in der Anbieter während der Präfixauflösung abgefragt werden. Dieser Wert wird unter dem folgenden Schlüssel gespeichert:

HKLM\System\CurrentControlSet\Control\NetworkProvider\Order

Einzelne Providernamen im ProviderOrder-Registrierungswert werden durch Kommas ohne führende oder nachfolgende Leerzeichen getrennt.

Beispielsweise könnte dieser Wert die Zeichenfolge enthalten:

RDPNP,LanmanWorkstation,WebClient

Angesichts eines UNC-Pfads \\<server>\<share>\<path> gibt MUP eine Präfixauflösungsanforderung aus, wenn das Präfix (z. B. \\server\share oder \\server) im MUP-Präfixcache nicht gefunden wird. MUP sendet eine Präfixauflösungsanforderung an jeden Provider in der folgenden Reihenfolge, bis ein Provider das Präfix fordert oder alle Provider abgefragt wurden:

1. TS-Client (RDPNP)

2. SMB-Redirector (LanmanWorkstation)

3. WebDAV-Redirector (WebClient)

Änderungen am Registrierungswert ProviderOrder erfordern einen Neustart, um in MUP wirksam zu werden.

Der MUP verwendet jeden aufgeführten Providernamen, um den Registrierungsschlüssel des Providers unter dem folgenden Registrierungsschlüssel zu finden:

HKLM\System\CurrentControlSet\Services\<ProviderName>

Der MUP liest dann den DeviceName-Wert unter dem NetworkProvider-Unterschlüssel, um den Gerätenamen zu finden, mit dem der Provider registriert wird. Wenn sich der Anbieter tatsächlich registriert, gleicht MUP den übergebenen Gerätenamen mit der Liste der Gerätenamen bekannter Anbieter ab. Anschließend wird der Anbieter in eine sortierte Liste für die Präfixauflösung platziert. Die Reihenfolge der Provider in dieser Liste basiert auf der Reihenfolge, die im oben beschriebenen ProviderOrder-Registrierungswert angegeben ist.

Diese Provider-Reihenfolge wird auch vom Multiple Provider Router (MPR), dem Benutzermodus-DLL, der die Netzwerkverbindungen basierend auf Abfragen an WNet-Provider herstellt, berücksichtigt.

Der MUP gibt die Präfixauflösungsanforderung fortlaufend aus und wird beendet, sobald der erste Provider das Präfix angibt. Wenn also im vorherigen Beispiel RDPNP ein Präfix beansprucht, ruft MUP die SMB- oder WebDAV-Redirectors nicht auf.

„Serielle Präfixauflösung“ verhindert (im Vergleich zur parallelen), dass ein Netzwerk-Redirector mit niedrigerer ProviderOrder-Priorität Leistungsprobleme für einen Netzwerkumleitungsanbieter mit höherer ProviderOrder-Priorität verursacht. Stellen Sie sich beispielsweise einen Remote-Server mit einer Firewall vor, die so konfiguriert ist, dass sie bestimmte Arten von TCP/IP-Paketen blockiert (z. B. Zugriff auf HTTP), andere jedoch zulässt (z. B. SMB-Zugriff). Selbst wenn der SMB-Netzwerk-Redirector als erster Provider im ProviderOrder-Wert konfiguriert ist und das Präfix schnell beansprucht, kann der WebDAV-Redirector in diesem Fall den Abschluss der Präfixauflösung erheblich verzögern, indem er auf das Timeout der TCP-Verbindung wartet.