検索
連載

第21回 ファイル共有プロトコルSMB/CIFS(その2)基礎から学ぶWindowsネットワーク(2/3 ページ)

Windowsネットワークの核心、SMB/CIFS解説の第2回。SMBプロトコルにおけるリソースの公開とその使用までの処理を追う。

Share
Tweet
LINE
Hatena

ネットワーク・リソースの利用開始までの流れ

 ユーザーから見たSMBプロトコルの操作方法については前回解説した。今回は、それらが実際にSMBプロトコル上でどのように動作しているかを見ていこう(以下では、SMB/CIFSをまとめてSMBと呼ぶ)。

 SMBプロトコルにおけるリソースの利用開始までの(典型的な)処理の流れをまとめると、次の図のようになる。


SMBリソース利用開始までの流れ
最初にSMBプロトコルの機能レベルのネゴシエーションがあり、それからサーバのファイル公開サービスへの接続(セッションの確立)、公開リソースへの接続(ツリー接続)へと続く。
 (1)プロトコルのネゴシエーションでは、お互いがサポートしている機能レベルを報告し、相互にどの機能までが利用できるかを確認する。これにより、プロトコルのバージョンによる差異を超えて、相互に接続・運用することができる。
 (2)ユーザー名とパスワード(およびドメイン名)などを指定して、サーバのファイル公開サービスに接続する。認証にパスしなければ、リソースにはアクセスできない。
 (3)サーバの公開リソースに接続する。この場合にはアクセス権限のチェックが行われるが、これはセッション・セットアップ時に使用したユーザー認証情報がそのまま使われる。

 最初にSMBプロトコルの機能レベルのネゴシエーションがあり、それからサーバのファイル公開サービスへの接続(セッションの確立)、公開リソースへの接続(ツリー接続)へと続く。以下ではこれらの各段階をより詳細に見ていく。

段階1――トランスポート層レベルの接続確立

 SMBによるファイル共有サービスを利用するためには、最初にサーバとクライアント間でトランスポート層レベルの接続を確立する必要がある。これについてはすでに述べたように、NetBIOSのセッション・サービスのほか、現在のWindowsネットワークでは、単一のTCP接続(デフォルトではポート445番)を使ったサービス(CIFS)も利用している。NetBIOSではTCP/IPだけでなく、NetBEUIやIPX/SPXといった下位プロトコルを利用しているため、最終的にはサーバとクライアント間はTCP/IP以外のプロトコルを使って接続することも可能だ。いずれの下位プロトコルを使用した場合でも、最終的にはやりとりされる上位のSMBプロトコルの通信内容にほとんど差はない。

 なおWindows 2000以降のWindows OSでは、NetBIOSとCIFSの両方を使ってトランスポート層レベルの接続を同時に試行し、両方接続した場合でも、どちらか一方しか利用しないようになっている。ネットワークのトラフィックは少々増えるかもしれないが(接続開始時に数パケットやり取りされるだけなので、全体から見れば影響はほとんどない)、順番に試行するよりも、接続に要する時間は抑えられている。

段階2――プロトコルのネゴシエーション(機能レベルのすり合わせ)

 SMBプロトコル・レベルで見たファイル共有の最初の段階は、サーバとクライアント間での「プロトコルのネゴシエーション」シーケンスから始まる。

 ネゴシエーション(折衝)とは、サーバとクライアントがそれぞれサポートしている機能レベルをお互いにすり合わせることを指す。すでに述べたように、SMBプロトコルでサポートされている機能(API)にはいくつかのレベルがあり、OSのバージョンやサーバおよびクライアントのソフトウェアによって利用できる機能が異なる。これらの違いを正しく認識し、相手側がサポートしていないレベルのコマンド(API)を送信しないようにするために必要なのが、このネゴシエーション・シーケンスである。

 具体的には、クライアントがサーバに接続するときに、クライアント側が自分自身でサポートしている機能レベルの一覧リスト(ダイアレクト文字列のリスト)をサーバに渡す。するとサーバ側では、クライアントが解釈可能な機能レベルのうち、最も適切なもの(最も機能レベルが高いもの)を選択して返す。ネゴシエーションが完了すると、以後クライアント側では、サーバ側から指示されたレベルもしくはそれ以下のレベルの機能のAPIだけを呼び出すようになる。

 このような仕組みにより、相手の(サーバ側の)バージョンに合わせて、適切なAPIだけを発行するようになっている。機能レベルが変われば利用できるAPIが変わるだけでなく、セキュリティ・モデル(「共有レベル」か「ユーザー・レベル」かの違い※1)やユーザーの認証方法(認証に利用するアルゴリズム)なども変わってくる。

※1 セキュリティ・モデル
 Windowsネットワークで利用されるアクセス管理(パスワード管理)の方法には、「共有レベル」と「ユーザー・レベル」という2つのセキュリティ・レベルがある。利用するリソースのタイプ(実際にはサーバのタイプ)に応じてこれらを使い分ける必要がある。

■「共有レベル」のアクセス管理
 初期のMS-Networksのころに使われていたアクセス管理の方法。リソースごとにアクセスを許可するためのパスワードが付けられており、リソースを利用する場合は、そのパスワード情報を指定する必要がある。パスワードには、読み取り専用と、読み書き可能の2種類のパスワードを付けることができる。例えばshare1というリソースにそれぞれpass1とpass2というパスワードが付けられているとすると、share1にpass1というパスワードでアクセスすれば内容を読み取ることができ、pass2というパスワードでアクセスすれば内容を変更することができる。パスワードさえ一致すれば、だれでもアクセスできる。

■「ユーザー・レベル」のアクセス管理
 LAN Managerを始め、現在のWindowsネットワークで一般的に利用されているアクセス管理の方法。リソースにはユーザーやグループごとにアクセス許可の管理が行われている。例えばユーザーAとグループBには読み取りアクセスを許可し、ユーザーCとグループDには読み書きアクセスを許可するというふうに管理する。より柔軟な管理が行える。リソースをアクセスするためには、ユーザー名とパスワードの両方を渡さなければならない(ドメイン環境ではドメイン名も渡す)。サーバ側では、自身が管理するユーザー・アカウント・データベースを参照したり、ドメインのユーザー管理モジュールを呼び出したりするなどして、正当なユーザーであるかどうかを認証し、パスした場合にだけアクセスを許可する。


 ネゴシエーションに利用される機能レベルは、実際には「ダイアレクト」を表す文字列を使って行われる。ダイレクト(dialect)とは方言という意味であり、バージョンなどの差に基づく、細部の差のことを表す。ネゴシエーションを要求するSMBパケットの中にこれらのダイアレクト文字列を埋め込んでおき、サーバ側ではどのダイアレクトまでサポートしているかを数値で返すことによって、お互いの機能レベルをすり合わせる。具体的なダイアレクトとしては、次のような文字列が使われている。ネットワーク・パケットを観察すると、これらの文字列がそのまま埋め込まれていることが分かるだろう。

ダイアレクト文字列 意味
PC NETWORK PROGRAM 1.0 最初のMS-Networksで利用されたプロトコル
PCLAN1.0 上記と同じ製品のブランド(販売元)が異なるバージョン
XENIX CORE Xenix(マイクロソフト社が販売していたUNIX製品)で利用されたプロトコル
MICROSOFT NETWORKS 1.03 MS-Networks 1.03で使用されていた
MICROSOFT NETWORKS 3.0 DOS用のLAN Manager 1.0プロトコル
LANMAN1.0 LAN Manager 1.0プロトコル。ユーザー・レベル・セキュリティが実装された
Windows for Workgroups 3.1a Windows 3.xに実装されたプロトコル
DOS LM1.2X002 DOS用のLAN Manager 2.0プロトコル
LM1.2X002 LAN Manager 2.0プロトコル
DOS LANMAN2.1 DOS用のLAN Manager 2.1プロトコル
LANMAN2.1 LAN Manager 2.1プロトコル
NT LM 0.12 Windows NT以降のプロトコル
SMB/CIFSプロトコルで利用されるダイアレクト文字列
現在のSMBプロトコルで利用されているダイアレクト文字列。これらの文字列が直接SMBプロトコルのネゴシエーション・パケット中に埋め込まれて渡される。基本的には、上にある方が機能レベルが低く、下にある方が機能レベルが高くなっている。現在のWindows OSでは、すべて「NT LM 0.12」をサポートしていることになっており、機能的な差はほとんどない。

 OSにもよるが、Windows 9xやWindows NT以降のOSではほとんど機能レベルには差がなく、すべて(現在の)最高レベルである「NT LM 0.12」というダイアレクトをサポートしている。以下にネゴシエーション・パケットの例を示す。


SMBプロトコルのネゴシエーション・パケット
ネゴシエーション段階では、クライアントは自身が理解可能なダイアレクトの一覧をサーバに送信する。するとサーバは、理解可能な最もレベルの高いダイアレクトのインデックスを返し、ネゴシエーションが完了する。
 (1)クライアントが送信しているネゴシエーション要求パケット。
 (2)このサーバは「# = 5」、つまり最後の「NT LM 0.12」を返している。
 (3)ダイアレクトの一覧。
 (4)ダイアレクトはテキスト文字列として渡されている。

 この例では、クライアントがサーバに渡した6つのダイアレクトに対し、サーバは「# = 5」、つまり最後の「NT LM 0.12」という応答を返している。これにより、クライアント側では、サーバに対して「NT LM 0.12」機能セットに含まれるAPIを発行するようになる。

Copyright© Digital Advantage Corp. All Rights Reserved.

ページトップに戻る