次の方法で共有

UNC 名前付けと MUP のサポート

  • [アーティクル]

この記事では、ネットワーク リダイレクターが UNC 名前付けとマルチ UNC プロバイダー (MUP) をサポートする方法について説明します。

MUP は、UNC (均一な名前付け規則) を使用して識別されたネットワーク リソースを見つけるのに役立つ Windows サービスです。 これは、UNC 名を使用してすべてのリモート ファイル システム アクセスを、リモート ファイル システム要求を処理できるネットワーク リダイレクター (UNC プロバイダー) にチャネル化するカーネル モード コンポーネントです。 MUP は、アプリケーションが UNC パスを使用する場合に関係します。たとえば、次のようなコマンド ライン コマンドです。

notepad \\server\public\readme.txt

MUP は、アプリケーションから UNC 名を含むコマンドを受け取ります。 この名前は、登録されている各 UNC プロバイダー、LAN Manager ワークステーション、およびインストールされているその他のワークステーションに送信されます。 UNC プロバイダーが UNC 名を独自の名前として識別すると、MUP はその名前の将来のインスタンスをそのプロバイダーに自動的にリダイレクトします。

マップされたドライブ文字 ("NET USE" コマンドなど) を作成する操作中、MUP は関与しません。 この操作は、ネットワーク リダイレクターの複数プロバイダー ルーター (MPR) とユーザー モード Windows ネットワーク (WNet) プロバイダー DLL によって処理されます。 ただし、ユーザー モードの WNet プロバイダー DLL は、この操作中にカーネル モード ネットワーク リダイレクター ドライバーと直接通信できます。

Windows Vista より前では、分散ファイル システム (DFS) ドライブを表さないマップされたドライブに対して実行されたリモート ファイル操作は、MUP を経由しません。 これらの操作は、ドライブ文字マッピングを処理したネットワーク プロバイダーに直接移動します。

Windows Vista で導入された更新されたリダイレクター モデルに準拠するネットワーク リダイレクターの場合、マップされたネットワーク ドライブが使用されている場合でも MUP が関係します。 マップされたドライブで実行されるファイル操作は、MUP を経由してネットワーク リダイレクターに移動します。 この場合、MUP は、関係するネットワーク リダイレクターに操作を渡すだけです。

MUP は、DFS (分散ファイル システム) クライアントも含む、 mup.sys バイナリの一部です。

カーネル ネットワーク リダイレクターには、通常、リモート リソースへの接続の確立をサポートするユーザー モードの WNet プロバイダー DLL もあります (ドライブ文字をリモート リソースにマッピングするなど)。 MPR は、WNet プロバイダーへのクエリに基づいてネットワーク接続を確立するユーザー モード DLL です。 MPR の呼び出しは、次のいずれかの操作の結果です。

  • コマンド プロンプトから発行された net use x: \\server\share コマンド。

  • Windows エクスプローラーから確立されたネットワーク ドライブ文字接続。

  • WNet 関数への直接呼び出し。

UNC 名を処理するには、ネットワーク リダイレクターを MUP に登録する必要があります。 複数の UNC プロバイダーが MUP に登録されている可能性があります。 これらの UNC プロバイダーには、次のリダイレクターの 1 つ以上を指定できます。

  • サーバー メッセージ ブロック (SMB) リダイレクターや WebDAV リダイレクターなど、RDBSS に基づくネットワーク ミニ リダイレクター。
  • RDBSS に基づいていないレガシ リダイレクター。

プレフィックス解決

MUP は、名前ベースの操作 (通常はIRP_MJ_CREATE要求) で UNC パスを処理できるプロバイダーを決定します。 この決定は、"プレフィックス解決" と呼ばれます。プレフィックス解決操作には、次の 2 つの目的があります。

  • プレフィックス解決の結果として発生した名前ベースの操作は、プレフィックスを要求するプロバイダーにルーティングされます。 成功した場合、MUP は後続のハンドルベースの操作 (IRP_MJ_READ や IRP_MJ_WRITE など) が、MUP を完全にバイパスする同じプロバイダーに確実に移動します。

  • プロバイダーとその要求されたプレフィックスは、MUP が保持するプレフィックス キャッシュに入力されます。 後続の名前ベースの操作では、MUP はこのプレフィックス キャッシュを使用して、プレフィックス解決を実行する前にプロバイダーが既にプレフィックスを要求しているかどうかを判断します。 このプレフィックス キャッシュ内の各エントリは、キャッシュに追加されるとタイムアウト (TTL と呼ばれます) の影響を受けます。 このタイムアウトが切れるとエントリがスローされます。この時点で、MUP は後続の名前ベースの操作でこのプレフィックスのプレフィックス解決を再度実行します。

MUP は、MUP に登録されているネットワーク リダイレクターに IOCTL_REDIR_QUERY_PATH 要求を発行することで、プレフィックス解決を実行します。 IOCTL_REDIR_QUERY_PATHの入力バッファーと出力バッファーは、非ページ プールから割り当てられます。

ネットワーク リダイレクターは、IRP 構造体の RequesterMode メンバーが KernelMode であることを確認することによって、この IOCTL のカーネル モードの送信者のみを許可する必要があります。

MUP は、要求情報に QUERY_PATH_REQUEST 構造を使用します。

UNC プロバイダーは、応答情報に QUERY_PATH_RESPONSE 構造を使用する必要があります。

FsRtlRegisterUncProvider を呼び出して MUP に UNC プロバイダーとして登録するレガシ ネットワーク リダイレクター (RDBSS を使用しない) はIOCTL_REDIR_QUERY_PATH要求を受け取ります。

UNC プロバイダーとしてのサポートを示すネットワーク ミニ リダイレクターは、IRP_MJ_CREATE呼び出しであるかのようにこのプレフィックス要求を受け取ります。 この作成要求は、FILE_CREATE_TREE_CONNECTION フラグが設定されたユーザー モードの CreateFile 呼び出しに似ています。 ネットワーク ミニ リダイレクターは、 MRxLowIOSubmit[LOWIO_OP_IOCTL]の呼び出しとしてプレフィックス要求を受け取りません。 プレフィックス要求の場合、RDBSS は MRxCreateSrvCall 要求をネットワーク ミニ リダイレクターに送信し、その後、 MRxSrvCallWinnerNotify および MRxCreateVNetRoot を呼び出します。 ネットワーク ミニ リダイレクターが RDBSS に登録されると、RDBSS は、内部 RDBSS エントリ ポイントを指すネットワーク ミニ リダイレクターのドライバー ディスパッチ テーブルをコピーします。 RDBSS は、ネットワーク ミニ リダイレクターの内部でこの IOCTL_REDIR_QUERY_PATH を受信し、 MRxCreateSrvCall、 MRxSrvCallWinnerNotify、および MRxCreateVNetRoot を呼び出します。 元の IOCTL_REDIR_QUERY_PATH IRP は、 MRxCreateSrvCall ルーチンに渡されるRX_CONTEXT構造体に含まれています。 さらに、 MRxCreateSrvCall に渡されるRX_CONTEXT内の次のメンバーが変更されます。

  • MajorFunction メンバーは、元の IRP が IRP_MJ_DEVICE_CONTROL された場合でも、IRP_MJ_CREATE に設定されます。
  • PrefixClaim.SuppliedPathName.Buffer メンバーは、QUERY_PATH_REQUEST 構造体の FilePathName メンバーに設定されます。
  • PrefixClaim.SuppliedPathName.Length メンバーは、QUERY_PATH_REQUEST 構造体の PathNameLength メンバーに設定されます。
  • Create.NtCreateParameters.SecurityContext メンバーは、QUERY_PATH_REQUEST 構造体の SecurityContext メンバーに設定されます。
  • Create.ThisIsATreeConnectOpen メンバーは TRUE に設定されます。
  • Create.Flags メンバーには、RX_CONTEXT_CREATE_FLAG_UNC_NAME ビットが設定されています。

ネットワーク ミニ リダイレクターがプレフィックス要求の詳細を表示する場合は、 MRxCreateSrvCall に渡された RX_CONTEXT でこれらのメンバーを読み取ることができます。 それ以外の場合は、サーバー共有への接続を試み、 MRxCreateSrvCall 呼び出しが成功した場合に STATUS_SUCCESS を返すことができます。 RDBSS は、ネットワーク ミニ リダイレクターに代わってプレフィックス要求を行います。

ネットワーク ミニ リダイレクターがこの IOCTL を直接受信する場合が 1 つあります。 ネットワーク ミニ リダイレクターは、RDBSS を初期化して登録する前に、ドライバー ディスパッチ テーブルのコピーを保存できます。 RxRegisterMinirdr を呼び出して RDBSS に登録した後、ネットワーク ミニ リダイレクターは、RDBSS によってインストールされた新しいドライバー ディスパッチ テーブル エントリ ポイントのコピーを保存し、元のドライバー ディスパッチ テーブルを復元できます。 復元されたドライバー ディスパッチ テーブルを変更する必要があります、ネットワーク ミニ リダイレクターに関心のある IRP の受信 IRP を確認した後、呼び出しが RDBSS ドライバーディスパッチ エントリ ポイントに転送されます。 RDBSS は、ドライバーが RDBSS を初期化し、 RxRegisterMinrdr を呼び出すときに、ネットワーク ミニ リダイレクターのドライバー ディスパッチ テーブルをコピーします。 rdbsslib.lib にリンクす るネットワーク ミニ リダイレクターは、その DriverEntry ルーチンから RxDriverEntry を呼び出す前に、元のドライバー ディスパッチ テーブルを保存して RDBSS スタティック ライブラリを初期化し、 RxRegisterMinrdr を呼び出した後にドライバー ディスパッチ テーブルを復元する必要があります。 この要件は、RDBSS が、 RxDriverEntry ルーチンと RxRegisterMinrdr ルーチンの両方のネットワーク ミニ リダイレクター ディスパッチ テーブルを介してコピーされるためです。

REG_SZ ProviderOrder レジストリ値は、プレフィックス解決中にプロバイダーを照会する順序を制御します。 この値は、次のキーの下に格納されます。

HKLM\System\CurrentControlSet\Control\NetworkProvider\Order

ProviderOrder レジストリ値の個々のプロバイダー名は、先頭または末尾に空白を付けずにコンマで区切られます。

たとえば、この値には次の文字列が含まれる場合があります。

RDPNP,LanmanWorkstation,WebClient

UNC パス \\<server>\<share>\<path> を指定すると、MUP プレフィックス キャッシュにプレフィックス (\\server\share や \\server など) が見つからない場合、MUP はプレフィックス解決要求を発行します。 MUP は、プロバイダーがプレフィックスを要求するまで、またはすべてのプロバイダーが照会されるまで、次の順序でプレフィックス解決要求を各プロバイダーに送信します。

  1. TS クライアント (RDPNP)

  2. SMB リダイレクター (LanmanWorkstation)

  3. WebDAV リダイレクター (WebClient)

ProviderOrder レジストリ値を変更するには、再起動を MUP で有効にする必要があります。

MUP では、一覧表示されている各プロバイダー名を使用して、次のレジストリ キーの下にあるプロバイダーのレジストリ キーを検索します。

HKLM\System\CurrentControlSet\Services\<ProviderName>

その後、MUP は NetworkProvider サブキーの下の DeviceName 値を読み取り、プロバイダーが登録するデバイス名を見つけます。 プロバイダーが実際に登録すると、MUP は、渡されたデバイス名と既知のプロバイダーのデバイス名の一覧と一致します。 次に、プレフィックス解決のためにプロバイダーを順序付きリストに配置します。 この一覧のプロバイダーの順序は、前に説明した ProviderOrder レジストリ値で指定された順序に基づいています。

WNet プロバイダーへのクエリに基づいてネットワーク接続を確立するユーザー モード DLL であるマルチ プロバイダー ルーター (MPR) も、このプロバイダーの順序に準拠します。

MUP はプレフィックス解決要求を順次発行し、最初のプロバイダーがプレフィックスを要求するとすぐに停止します。 したがって、前の例では、RDPNP がプレフィックスを要求した場合、MUP は SMB または WebDAV リダイレクターを呼び出しません。

"シリアル プレフィックス解決" (並列) では、ProviderOrder 優先度が低いネットワーク リダイレクターが、ProviderOrder 優先度の高いネットワーク リダイレクターのパフォーマンスの問題を引き起こさないようにします。 たとえば、特定の種類の TCP/IP パケット (HTTP へのアクセスなど) をブロックし、他のサーバー (SMB (メガバイト) アクセスなど) を許可するように構成された、ファイアウォールが設定されたリモート サーバーについて考えます。 この場合、SMB ネットワーク リダイレクターが ProviderOrder 値の最初のプロバイダーとして構成され、プレフィックスを迅速に要求した場合でも、WebDAV リダイレクターは、TCP 接続がタイムアウトするのを待ってプレフィックス解決の完了を大幅に遅らせる可能性があります。