第21回 ファイル共有プロトコルSMB／CIFS（その2）：基礎から学ぶWindowsネットワーク（3/3 ページ）
Windowsネットワークの核心、SMB／CIFS解説の第2回。SMBプロトコルにおけるリソースの公開とその使用までの処理を追う。
段階3――セッション・セットアップ（サーバへのログオン）
ネゴシエーションが完了すれば、次は「セッションのセットアップ（準備）」シーケンスに移る。
セッションという用語は、例えばNetBIOSにおけるセッション・サービスなどでも利用されているが、ここではSMBサーバ・プロセスとSMBクライアント・プロセス間の通信路とその環境という意味で利用されている。
この段階では、認証に関する情報（ユーザー名やパスワード、ドメイン名などの情報）を送信してサーバ側に対して接続を要請する。接続が許可されると、サーバとクライアント間で通信路（セッション）が確立される。一度通信路が確立されると、そのクライアント（実際にはユーザー）が接続を終了するまで、同じセッションを利用して、SMBプロトコルのコマンドや結果、データなどがやりとりされる。ただしユーザー認証などをパスしないと、この接続要求は拒否され、セッションを確立することはできない。
確立されたセッションは、例えばサーバ側のコマンド・プロンプト上で「net session」というコマンドを実行すると表示される。
C:\>net session …セッションの表示
コンピュータ ユーザー名 クライアント オープン アイドル時間
------------------------------------------------------------------
\\192.168.1.111 USER01 Windows 2002 Serv 3 13:09:01
\\192.168.1.155 HIRO Windows 2002 2600 8 00:00:00
\\DPC19 DPC19$ Windows 2000 2195 1 12:31:05
\\DPC21 DPC21$ Windows 2002 Serv 0 10:58:05
\\SERVER01 Windows 2000 2195 0 00:00:39
コマンドは正常に終了しました。
ここでは全部で5つのセッションが確立され、アクティブになっている。オープンとは、そのセッション上でオープンされているファイルの数を表している。ただしWindowsネットワークの性質上、アイドル状態（無通信状態）のまま、ある一定時間経つと、自動的にこのセッションが切断されることがある。そのため現実のネットワークを観察すると、セッションの確立や切断はひんぱんに起こっていることが分かるだろう。一番下にユーザー名が空白になっているセッションがあるが、システム・アカウントで動作するサービスなどが接続を行った場合にこのように表示されるようである。
左端に表示されているのは、このサーバに接続しているクライアント側のコンピュータの名前である。ここには「\\DPC21」というふうに名前（NetBIOS名）が付いているものと、「\\192.168.1.111」のようにIPアドレスが付いているものの2種類があるが、これは利用しているトランスポート層プロトコルの違いによる。NetBIOS名が付いているものはNetBIOSのセッション・サービス（NBTならばTCPのポート139番）を利用しており、IPアドレスが付いているものはCIFS（TCPのポート445番）を利用して、それぞれサーバに接続していることを表す。これらTCPの接続情報はnetstatコマンドで調べることができるので（ただしNetBEUIやNetBIOS over IPX/SPXの場合はnetstatでは調査できない）、それぞれのクライアントがどのTCPポートを利用してサーバへ接続しているかをつき合わせてみるとよいだろう。例えば上記の「\\192.168.1.111」ならば、netstat -nコマンドで調べると、192.168.1.111からサーバのTCPポート445番へ接続していることが分かるはずである。また\\DAPC19ならば、このクライアント・コンピュータ（この名前に対するIPアドレスを見つける方法は関連記事のTIPSなどを参照）からサーバのTCPポート139番へ接続しているはずである。
セッションのより詳細な情報を見るには、「net session \\コンピュータ名」のようにすればよい。
C:\>net session \\192.168.1.155 …特定のセッションの表示
ユーザー名 HIRO …ユーザー名
コンピュータ 192.168.1.155
ゲスト ログオン No
クライアント タイプ Windows 2002 2600 Service Pack 1
セッション時間 16:27:00 …接続時間
アイドル時間 00:00:04
共有名 タイプ オープン数
------------------------------------------------------------------
IPC$ IPC …使用中のリソース
prj Disk 0
usr Disk 7
コマンドは正常に終了しました。
ここでは、（CIFSで接続している）192.168.1.155というIPアドレスを持つコンピュータが、このサーバ（net sessionを実行しているサーバ・コンピュータ）へ、どういうユーザー名で接続しているか、どのリソースを利用しているかなどの情報が表示される。また、「net session \\コンピュータ名 /delete」とすれば、このセッションを強制的に切断することができる。
段階4――ツリー接続（リソースへの接続）
セッションが確立され、それが許可されると、いよいよサーバの公開リソースを利用できるようになる。
SMBプロトコルでは、公開されたリソースを利用することを「ツリー接続する」という。\server01の下にある\share1や\share2、\share3などが、ちょうど1つのツリーのようになっていることから（\\server01\share1、\\server01\share02、……）、このように呼ばれているものと思われる。
ツリーに接続する場合に利用されるユーザー・アカウント情報としては、セッションを確立する時点で利用されたユーザー名とパスワード、ドメイン名などの情報がそのまま使われる。公開リソースには（通常）何らかのアクセス権が設定されているだろうが、これらのアクセス権とセッション接続時のアクセス権限によって、ツリーへの接続が許可されるかどうかが決まる。
段階5――リソースの利用
以上でサーバへの接続は完了である。あとはファイルをオープンしたり、読み書きしたりするコマンドを発行すればよい。具体的なSMBコマンドの一覧については、次回説明することにする。
セッションとリソース・ツリーの関係
ここまでは、SMBプロトコルにおける利用開始時の手続きについて見てきたが、ここでもう一度それらの関係についてまとめておこう。
サーバ上のリソースを利用するためには、最初にトランスポート層レベルでサーバへの通信路を確保し、次にSMBレベルでセッションを確立してから、さらに実際のサーバ上のリソースへの接続を行う。これをネットワーク・レベルでみた図にすると、次のような状態になる。
セッションとリソース・ツリーの関係
最初にサーバとクライアント間でSMBプロトコルをやり取りするためのバーチャル・サーキット（仮想回線）を開設する（ここまでは、SMBの下位のトランスポート層プロトコルの役割）。そして、そのバーチャル・サーキットを通じてサーバ側とクライアント側のプロセス間でセッションを確立し、それが成功すれば、リソースの利用を要求する。
クライアントとサーバの間で最初に確立する通信路を、SMBプロトコルでは「バーチャル・サーキット（仮想回線）」と呼んでいるが、この図では、一番外側のピンク色のパイプがその役割りを果たしている。このバーチャル・サーキットは、当初のSMBプロトコルではNetBEUI上のNetBIOSセッション・サービスを利用することが想定されていたが、現在ではTCP/IPやIPX/SPX上のNetBIOSセッション・サービスでもよいし、CIFSのように、単一のTCP接続（ポート445番を使用）を利用してもよい。いずれの方法であってもクライアントとサーバ間にストリーム型の通信路が用意されればよい。ただし実際のWindows OSでは、NBTやCIFSのポート番号を変更するような機能はサポートされておらず、これら標準以外のプロトコルやポート番号を利用することは事実上不可能となっている。せいぜい、NetBIOSとCIFSのどちらを利用するかを選ぶくらいしかできない。
バーチャル・サーキットが確立されれば、それを使って、次はいよいよSMBセッションの確立が行われる。すでに見てきたように、まずSMBプロトコルの機能レベルのネゴシエーションが行われ、次にユーザー名とパスワード、ドメインなどの情報を利用して、サーバへ接続する。
セッションの接続要求が受け付けられると、サーバからはセッションを識別するための番号としてUID（User ID）という情報が返される。ユーザーとセッションが1対1に対応しているから、このようにセッションIDではなく、ユーザーIDと呼ばれているようである。以後クライアントからは、このユーザーID（図中の緑色のパイプ）を使ってサーバへアクセスする。
セッションが確立すると、次はそのセッションを利用して、特定のリソースへの接続が行われる。図から分かるように、サーバ上の公開リソースへの接続は、セッションごとに行われる。一度確立したセッションを使って、サーバ上のリソース・ツリーへの接続を行うのである。サーバ上の複数のリソースを使う場合でも新たにセッションを開設する必要はなく、同じセッションを使って複数のリソース・ツリーへ接続することができる。別のサーバへ接続する場合は、またSMBプロトコルのネゴシエーションから始めるので、別のユーザー・アカウント情報を利用することができるし、同時に複数のサーバへ接続することもできる。
異なるユーザーでのセッション確立
セッションごとにユーザー・アカウント情報が決まるため、（サーバからみると）同一セッション内ではすべて同一のユーザーとして扱われることは分かっただろう。では、同一サーバ上の複数のリソースへ、異なるユーザー・アカウント情報を使って接続したい場合はどうすればよいのだろうか。例えばあるサーバserver01が、2つのリソースproject1とproject2を、それぞれ別のユーザー・アカウントuser1とuser2に対して許可していたとする。
このような場合は、前回の最後で述べた「net use \\サーバ名 /user:ユーザー名 パスワード」というコマンドを利用して、新しくセッションを開始すればよいと考えるかもしれない。だが実際にこれを実行すると、次のようなエラーとなる。
C:\>net use \\server01 /user:user1 password1 …接続1
コマンドは正常に終了しました。
C:\>net use \\server01 /user:user2 password2 …接続2。別アカウントを指定
システム エラー 1219 が発生しました。
同じユーザーによる、サーバーまたは共有リソースへの複数のユーザー名での複数の接続は許可されません。サーバーまたは共有リソースへの以前の接続をすべて切断してから、再試行してください。 …エラー
これは、あるサーバに対するセッションを、同じユーザーからは実行できないということを表している。とはいうものの、これはSMBプロトコルの制限によるエラーではなく、SMBプロトコルを利用するクライアント側のシェルの設計による。もしこのような接続を許すとすると、2つのセッションを区別する方法がなくなるので、わざとエラーにしているようである。例えば同じ公開リソースに対してuser1とuser2の両方のユーザー・アカウントでnet useで接続した場合、いずれのリソースも\\server1\resource\〜となり、どちらのセッションを利用するかを指定することはできない。そのため接続そのものをエラーにしているようである。
それでは、エクスプローラやコマンド・プロンプトを使う場合、このような方法がまったく不可能かというとそうではない。先の図から分かるように、別のバーチャル・サーキットを利用させるようにすれば別のセッションが生成されるので、これを実現できる（ただしかなりトリッキーな方法なので、SMBプロトコルの理解のため以外にはあまり有用ではないが）。具体的には、「net use \\サーバ名」で利用するサーバ名を、すべて異なる文字列表現になるようにすればよい。
C:\>net use \\server01 /user:user01 password1 …セッション1
コマンドは正常に終了しました。
C:\>net use \\server01.d-advantage.local /user:user02 password2 …セッション2
コマンドは正常に終了しました。
C:\>net use \\192.168.1.11 /user:user03 password3 …セッション3
コマンドは正常に終了しました。
C:\>net use
新しい接続は記憶されません。
ステータス ローカル名 リモート名 ネットワーク名
…以下、3つのセッションが生成されている
------------------------------------------------------------------
OK \\192.168.1.11\IPC$ Microsoft Windows Network
OK \\server01.d-advantage.local\IPC$
Microsoft Windows Network
OK \\server01\IPC$ Microsoft Windows Network
コマンドは正常に終了しました。
この例では、FQDN名、IPアドレス、NetBIOS名でそれぞれサーバを指定している。こうすると、FQDN名とIPアドレスで指定した場合はCIFSで、NetBIOS名で指定した場合はNBTでそれぞれ接続される（Windows 2000よりも前のOSではCIFSは利用できない）。これらのリソースを使う場合は、「\\192.168.0.11\share1\file1」「\\server01.d-advantage.local\share1\file1」「\\server01\share1\file1」のように使い分ければよい。
SMBにおけるプロセス
これ以外にも、SMBのクライアント側のユーザー・プロセス環境を切り替えれば、同じサーバ上の同じリソースに接続することができる。先の図で分かるように、SMBプロトコルでは、セッションとは2つのプロセス間で確立する通信路のことを指す。実際のWindows環境では、これはクライアントやサーバにおけるネットワーク・ファイル・アクセス要求のリダイレクタ（へ要求を送信しているプロセス）に相当する。これらのプロセスはユーザー・セッションごとに用意されているので（ここでいうセッションとは、ユーザーがWindowsにログオンするごとに用意されるユーザー環境のこと）、コンソールへログオンするだけでなく、例えばTelnetセッションとしてログオンした環境なども含まれる。つまりコンソールでのログオンだけでなく、裏でTelnetで別ユーザーとしてログオンすれば、SMBプロトコル・レベルでみればまったく別のプロセス間でのセッションとなり、同じサーバ上の同じリソースへ接続することができる。
次回はSMBプロトコルのパケット構造やサポートされているAPIなどの詳細について解説する。
Copyright© Digital Advantage Corp. All Rights Reserved.