[Chapter 1] 1.4 Microsoft による実装

1.4 Microsoftによる実装

ここまでで様々な予備知識を解説し終えたので、MicrosoftによるCIFS/SMBネットワークの世界での前述した概念の実装について説明しよう。既に予期しているだろうが、これまでと同様に、複雑な概念が導入されることになる。

ワークグループとは、同じサブネットに属し、同じSMBグループに所属しているSMBコンピュータの集合体であることを思い出して欲しい。 Windowsドメインは、これを拡張したものである。SMBマシンで構成されるワークグループを一歩進めたものであって、サーバがドメインコントローラとして機能する。Windowsドメインを構成するために、 ドメインコントローラが必ず必要である[6]。そうでなければ、ただのワークグループに過ぎない。図 1.11.を参照して欲しい。

[6]WindowsドメインはMicrosoftからは"Windows NTドメイン"と呼ばれている。これは、Windows NTマシンがドメインコントローラの役割を果たすことを仮定したためにそう呼ばれるようになった。しかしながら、Sambaによって同様にドメインコントローラとしての機能が実現されるので、混乱を避けるために、単に"Windowsドメイン"と呼ぶことにする。

Figure 1.11: Windowsドメインの簡単な例

ドメインコントローラ(ログオンサーバ)では、2種類の別々なプロトコルが現在使われている:ひとつはWindows 95/98マシンと通信するためのプロトコル、もうひとつはWindows NTマシンと通信するためのプロトコルである。Sambaでは、現在Windows 95/98へのドメインコントローラプロトコルを実装している(Windows 9 xマシンのドメインコントローラとして機能可能である)が、Windows NTコンピュータへのプロトコルの完全なサポートはまだ行われていない。しかし、Sambaチームにより、Windows NTへのドメインコントローラプロトコルが来たるSamba 2.1でサポートされると約束されている。

どこが難しいのだろうか?。Windowsドメインコントローラがクライアント、他のドメインコントローラと通信する際に使用されるプロトコルは、企業秘密となっており、Microsoftから仕様が公開されていない。このためSamba開発チームは、ドメインコントローラプロトコルで、どのコードが特定のタスクを実行しているか調べるのに、リバースエンジニアリングを行わなければならないのだ。

1.4.1.1 ドメインコントローラ

ドメインコントローラはWindowsドメインの神経中枢であり、これはNISサーバがUnixネットワーク情報サービスの神経中枢であるのと同様である。ドメインコントローラは様々な役割を担っている。重要な役割の一つとして認証が挙げられる。認証とは、ユーザが他のマシン上の共有リソースにアクセスする際の許可や拒否を行なう処理であり、通常パスワードを用いることにより行われる。

それぞれのドメインコントローラは、ユーザ-パスワードの組合わせを保つのにセキュリティアカウントマネジャー (SAM)を使っている。ドメインコントローラは、ユーザ名に結び付けられたパスワード(一つのユーザに一つのパスワードが割り当てられる)の中央リポジトリとなっている。これにより、それぞれのクライアントマシンが、各々利用可能なネットワークリソースにアクセスするための、数多くのパスワードを保持するよりも効率的になっている。

Windowsドメインでは、認証されていないクライアントがサーバ上の共有にアクセスを要求した場合、サーバは首の向きを変えて、ドメインコントローラにユーザが認証されたユーザであるかどうか問い合わせを行う。正当なユーザであることが分かると、サーバはそのサービスとそのユーザに対応するアクセス権でもってセッション通信を確立する。ユーザ認証に失敗すると、接続は拒否される。ドメインコントローラによって、ユーザは一旦認証されると特殊な認証トークンがクライアントに与えられ、ユーザはドメイン上のその他のリソースにアクセスするためにログインし直す必要がなくなる。この時点でユーザは、ドメインに"ログイン"していると考えて良い。図 1.12.を参照して欲しい。

図 1.12: ドメインコントローラを使用した認証

1.4.1.2 プライマリとバックアップドメインコントローラ

冗長性はWindowsドメインの背後に存在している鍵となる思想である。ドメイン上で、現在稼働しているドメインコントローラは、プライマリドメインコントローラ(PDC)と呼ばれている。同様に、ドメイン上に一つまたはそれ以上のバックアップドメインコントローラ(BDC)が存在可能である。これはプライマリドメインコントローラが落ちたりアクセス不能になった際に、プライマリドメインコントローラに取って代わるものである。この必要が発生した場合に、BDCがクライアントに影響を与えずにDCサービスの移行を実施できるよう、BDCは頻繁にSAMデータの同期をプライマリドメインコントローラと行う。ただし、BDCはSAMの読み取り専用のコピーしか持たないことに注意して欲しい。;PDCと同期することによってのみデータを更新出来る。Windowsドメインのサーバは、プライマリもしくはバックアップドメインコントローラのSAMを、リソースにアクセスもしくはドメインにログオンしようとするユーザの認証に使用出来る。

多くの点で、WindowsワークグループとWindowsドメインは似通っている。この事は偶然ではなく、Windowsドメインの概念はWindows NT 3.5が登場するまで発展していなかったことと、Windows for Workgroups 3.1で用いていたワークグループに対する後方互換性をWindowsドメインが持たなければならなかったこととが原因である。ここで覚えておいて欲しい鍵となる事は、WindowsドメインはWindowsワークグループに一つあるいはそれ以上のドメインコントローラを追加しただけのものであるということである。

Sambaは、Windows 95/98マシンのプライマリドメインコントローラとして問題なく機能する。ただし、Samba 2.0は認証のためのプライマリドメインコントローラとしてのみ機能する；認証以外のPDCの機能は、現在まだ実装されていない(この記述を読む頃までには、Samba 2.1によってNTクライアントのPDCとしてSambaを使用出来るようになっているだろう)。同様にSAMデータを同期する際に使用されているプロトコルはMicrosoftによってクローズドにされているので、Sambaでは現在のところバックアップドメインコントローラとして機能しない。

1.4.2 ブラウジング

ブラウジングは、ユーザからの質問:"Windowsネットワークにどんなマシンが存在するの?"という問いに高いレベルで答えるものである。これはワールドワイドウェブのブラウザとは何の関係もない。「そこに何があるか調べる」という一般的な考え方は同じだし、「そこにあるもの」が警告無しに変化することがあるのも同じではあるが。

ブラウジング機能が利用できない場合、ユーザはネットワーク上の接続したい特定のコンピュータの名前を知っておく必要があり、アプリケーションやファイルマネージャからリソースにアクセスする際に、以下のようなUNCを手作業で入力する必要があった:

\\HYDRA\network\

一方、ブラウジング機能を利用すると、Windowsクライアントの「ネットワークコンピュータ」ウィンドウから、標準的なポイントアンドクリックのGUI操作でマシン内のデータを確認することが出来る。

1.4.2.1 ブラウジングのレベル

この章のはじめの方で示したように、実際にはSMB/CIFSネットワークで行われているブラウジングには2つのタイプがある:

(共有リソースも含めて)マシンの一覧をブラウズする
特定のマシンの共有リソースをブラウズする。

最初の内容を検討しよう。それぞれのWindowsワークグループ(ドメイン)のサブネット上では、一台のマシンが、ネットワーク上で現在のところアクセス可能なマシンの一覧を保持する機能を持っている。このコンピュータは ローカルマスタブラウザ と呼ばれており、保持されている一覧は ブラウズリストと呼ばれている。サブネット上のマシンは、ブラウジングの際に生じるネットワークトラフィックの量を削減するためにブラウズリストを使用する。それぞれのマシンが、現在のところ利用可能なマシンの一覧を決定するのに動的にポーリングを行う代わりに、単にコンピュータはローカルマスタブラウザに最新の完全な一覧を取得するための問い合わせを単に行うだけでよい。

マシン上の実際のリソースをブラウズするには、ユーザはその特定のマシンに接続しなければならない:この情報はブラウズリストからは取得出来ない。この情報は、Windows 95/98 あるいは NTのネットワークコンピュータにこのマシンのアイコンが表示されている時に、そのアイコンをクリックすれば取得出来る。この章の導入の部分で示したように、ユーザの認証がうまくいっていれば、そのマシンはアクセス可能な共有リソース一覧を提供する。

Windowsワークグループのそれぞれのサーバは、NetBIOS名を登録した後で、ローカルマスタブラウザに自身の存在を通知することが要求されている。また(理屈の上では)マシンの電源を切る際にワークグループから離脱すると通知する事が要求される。どんなサーバが通知されたかの記録は、ローカルマスタブラウザの責任となる。ローカルマスタブラウザは、初めの方で解説したNetBIOSネームサーバ(NBNS)と同じである必要はない。

注意:Windowsネットワークコンピュータは、奇妙な動作することがある:ブラウズを行う特定のマシンを選択するまで、ネットワークコンピュータのウィンドウに最新でないデータが表示されていることがある。すなわち、ネットワークコンピュータのウィンドウには、既にクラッシュしているマシンやマシン名の変更内容が更新されていないマシンが表示されていることがあるのだ。簡潔に言えば、一旦サーバを選択して接続を行えば、より確実に共有とプリンタがネットワークに実際に存在しているか知ることが出来る。

ドメインコントローラとは違って、ほとんど全てのWindowsマシン(NT Server、NT Workstation、98、95、更にはWindows 3.1 for Workgroup)がローカルマスタブラウザになることが出来る。ドメインコントローラの場合と同様に、ローカルマスタブラウザが落ちたりアクセス不能になった場合に移行出来るように、ローカルマスタブラウザは一つあるいはそれ以上の バックアップブラウザをローカルサブネット上に持つことが可能である。万全を期してローカルバックアップブラウザはブラウズリストをローカルマスタブラウザと頻繁に同期している。ローカルマスタブラウザとローカルバックアップブラウザを含むようにWindowsドメインの構成図を更新しよう。結果として図 1.13が示される。

図 1.13: ローカルマスタブラウザとローカルバックアップブラウザを含めたWindowsドメイン

ワークグループに配置されるバックアップブラウザの数の最小値は、次のように計算される。

Windows NTマシンの数が1台から32台まで、またはWindows 95/98マシンの数が1台から16台までのネットワーク上では、ローカルマスタブラウザは、ローカルマスタブラウザと同期するバックアップブラウザを1台設定する。
Windows NT マシンの数が33台から64台まで、またはWindows 95/98マシンの数が17台から32台の場合には、ローカルマスタブラウザは2台のバックアップブラウザを配置する。
これ以降は、32台のWindows NTマシン、または16台のWindows 95/98マシン毎に、ローカルマスタブラウザは、さらに別のバックアップブラウザを設定する。

現在の仕様では、ローカルマスタブラウザによって配置されるバックアップブラウザの数に上限は存在しない。

1.4.2.2 ブラウジング選定

ブラウジングは、Windowsワークグループの要となる要素である。ただし、全てのネットワーク上で完全に動作するわけではない。例えば、小規模な企業の最高経営責任者のデスクに置いてあるWindows NT Serverはローカルマスタブラウザである-彼がマシンの電源を切って、マッサージチェアでリラックスするまでは。電源が切られた時点で、在庫処理部にあるWindows NT Workstaionがローカルマスタブラウザの役割を引き継ぐだろう。でも、このコンピュータでは、巨大で下手くそなプログラムが走っていて、プロセッサを目一杯使っているかもしれない。教訓: ブラウジングはネットワークを出入りするサーバに対して柔軟に対応できなければならない。ほとんど全てのWindowsマシンがブラウザに選定されうるので、ある時点でどのマシンがローカルマスタブラウザを担うかを、選択する方法がなければならない。この決定過程は選定と呼ばれている。

選定アルゴリズムは、ほとんど全てのWindowsオペレーティングシステムに組み込まれているので、どのマシンがローカルマスタブラウザになるか、どのマシンがローカルバックアップブラウザになるのか、各マシン間で選定の合意が可能である。選定はいつでも行うことが可能である。例えば、最高経営責任者がマッサージを終えて、サーバを再起動したと仮定しよう。そのサーバがネットワークに接続し、自身の存在の通知を行うと、在庫管理部の PC がそのままマスターブラウザとなり続けるのかどうかをチェックするために選定が行われる。

選定が行われる際に、各マシンはデータグラムを通して自身に関する情報をブロードキャストする。この情報には以下のものが含まれる:

使用される選定プロトコルのバージョン
そのマシン上のオペレーティングシステム
そのクライアントがネットワーク上に存在している時間の合計
そのクライアントのコンピュータ名(monyo 訳注: 原文は hostname だが、厳密には正しくない)

これらの値により、どのオペレーティングシステムが優先権を持つか決定が行われ、ローカルマスタブラウザの役割を担当するマシンを決定される。 (Chapter 6, ユーザ、セキュリティ、ドメイン,に選定過程についてより詳細に述べられている)。この機能の実装に使われたアーキテクチャは、優れたものではない。また、セキュリティ上の問題も含んでいる。一方、ドメインで行われるブラウジングでは、ドメインでのセキュリティが組み込まれており、選定アルゴリズムでは、どのコンピュータがブラウザになるか考慮されていない。従って、ブラウザサービスを実行しているすべてのマシンによって、ブラウザ選定に参加するように自身を登録し(ブラウザ選定に勝利した後)ブラウザリストの変更を行うことが必要となる。ただし、ブラウジングはWindowsマシンによるネットワークでの鍵となる特徴であって、また下位互換性の必要性によって、ずっと使い続けられてきた。

1.4.3 Windowsワークグループは、複数のサブネットをまたぐことが出来るか?

この質問への答えは、可能であると言える。ただし、複数のサブネットをまたがったワークグループを構築した人の多くは、頭を抱えたに違いない。Windows NT 3.5、Windows for Workgroupは、複数のサブネットをまたぐことを、最初に想定してデザインされていなかった。その結果として、現実には、2つあるいは、それ以上のサブネットをまたいでいるWindowsドメインは、同じワークグループ名を共有する2つあるいは、それ以上のワークグループを結びつけたものになっている。よい知らせとして、プライマリドメインコントローラで、各サブネット越しの認証をコントロール出来ることが挙げられる。悪いニュースとして、ブラウジングに関して面倒なことが挙げられる。

以前述べたように、各サブネットには、ローカルマスタブラウザがなければならない。Windowsドメインで複数のサブネットをまたぐ際に、システム管理者はドメインマスタブラウザとなるマシンを1台用意する必要がある。ドメインマスタブラウザは、完全なWindowsドメインのブラウズリストを保持する。このブラウズリストは、各ローカルマスタブラウザのブラウズリストをドメインマスタブラウザのブラウズリストに、定期的に同期することにより生成される。同期が行われた後、ローカルマスタブラウザとドメインマスタブラウザには、特定の領域のブラウズリストが格納される。図1.14の例を見て欲しい。

図 1.14: 一つ以上のサブネットをまたぐワークグループ

素晴らしく見えないだろうか。残念ながら、以下の理由によって理想通りにならない:

プライマリドメインコントローラが存在するなら、常にそれがドメインマスタブラウザの役割を演じる。マイクロソフトの実装により、ドメインマスタブラウザとプライマリドメインコントローラは、常にNetBIOSリソースタイプ<1B>を共有し、(不運なことであるが)分離することが出来ない。
Windows 95/98はドメインマスタブラウザになることも、 通信することさえ出来ない(monyo 訳注: 実際はWindows 95/98 がローカルマスタブラウザとしてドメインマスタブラウザと通信することは可能である) 。このことは、Sambaユーザの間では、複数のサブネットにまたがるワークグループにおける各サブネットで、少なくとも1台のWindows NT マシン(またはSambaサーバ)を顧客に購入させようとするMicrosoftのマーケティング上の意思決定であるように思われている。

各サブネットのローカルマスタブラウザは、所属するサブネットのブラウズリストを保持して、このサブネットの情報を管理する。したがって、コンピュータが自身が所属するサブネットにあるサーバの一覧を調べる際には、そのサブネット上のローカルマスタブラウザが問い合わせを受ける。コンピュータは、自身の所属するサブネットの外にあるサーバの一覧を調べようとした場合にも、ローカルマスタブラウザに問い合わせを行うだけでよい。サブネット上のローカルマスタブラウザの管理するブラウズリストが指定された間隔でドメインマスタブラウザと同期され、xxxxxるからである。このドメインマスタブラウザでは、ドメイン上のその他のサブネットのローカルマスタブラウザとの同期が行われている。このことは、 ブラウズリスト伝播と呼ばれている。

必要であれば、SambaはWindowsドメインでドメインマスタブラウザになることが可能である。更に、Windowsサブネットのローカルマスタブラウザにもなれ、ドメインマスタブラウザとブラウズリストの同期を行うこともできる。

1.4.4 Windows Internet Name Service(WINS)

Windows Internet Name Service (WINS)は、NetBIOS name server (NBNS)のMicrosoftによる実装である。当然、WINSでは、NetBIOSの多くの特徴が継承されている。まず、WINSはフラットである: マシンに付けられる名前はfredのようなもので、ワークグループもCANADA、USAというような名前しか使えない。更に、WINSは動的である:クライアントがネットワークに最初に接続した際には、自身のホスト名、アドレス、ワークグループ名をローカルなWINSサーバに通知するように要求される。WINSサーバは、クライアントが定期的にWINSへの登録を更新する限り、その情報を保持する。WINSへの登録によって、クライアントがネットワークにまだ接続していることが明らかになる。WINSサーバは、ドメイン、ワークグループ特有のものではなく、どちらでも使用可能であって、どのようなクライアントに対しても有効である。

複数のWINSサーバは、指定された間隔で、お互いに同期するように設定可能である。これによって、ネットワーク上でオンラインまたはオフラインになるマシンの登録結果を、ひとつのWINSサーバから他のマシンに通知することが可能となる。理屈上では、効率的に思えるが、ネットワークを管轄する複数のWINSサーバが存在する場合には、あっという間に管理が困難となるだろう。WINSサービスは複数のサブネットをまたぐことが出来るので(クライアントごとにWINSサーバのアドレスを直接指定することも、DHCPを通して取得させることもも可能である)、Windowsドメインがいくつあるかによらず、ひとつのWINSサーバにすべてのWindowsクライアントから自分の登録を行わせたほうが、効率的であることが多い。こうすれば、正しい情報を持った信頼すべきWINSサーバは一台ですむ。複数のWINSサーバが最新の変更を同期するよう格闘を続けなくても良いのである。

その時点で活動しているWINSサーバは、 プライマリWINSサーバと呼ばれている。同様にセカンダリWINSサーバを導入することも可能である。これによって、プライマリWINSサーバが落ちたり、アクセス不能になったような場合のトラブルの発生を防ぐことが出来る。どのマシンがプライマリまたはバックアップWINSサーバになるのかを決定する選定はないことに注意して欲しい - WINSサーバの選択は静的であって、システム管理によってあらかじめ決定されていなければならない。プライマリWINSサーバ、バックアップWINSサーバは双方供に、アドレスデータベースを定期的に同期する。

Windows系例のオペレーティングシステムでは、NT Workstationまたは、NT ServerでないとWINSサーバとして動作することが出来ない。SambaはプライマリWINSサーバとして機能できるが、セカンダリWINSサーバとしては機能出来ない。

1.4.5 Sambaで実現できる機能

やれやれ!。Microsoftネットワークがこんなに複雑だと思いもしなかったよね。Sambaが手助け出来ることを示して締めくろう。表表 1.6では、Windows NTドメイン、WindowsワークグループでSambaが実現不可能な機能を要約している。ご覧になると分かるだろうが、多くの点でNTドメインプロトコルは独占的(Microsoftにより文書化されてこなかった)なので、Microsoftのサーバとデータを正確に同期することが出来ず、多くの機能でバックアップとしての動作が出来ない。しかしながら、Samba バージョン2.0. xでは、限定的ながらプライマリドメインコントローラの認証プロトコルをサポートし、日々多くの機能を取り込んでいる。

表1.6: Sambaで実現可能な役割(2.0.4b時点)
役割	実行可能/不可能
ファイルサーバ	可能
プリントサーバ	可能
プライマリドメインコントローラ	可能(Samba 2.1以降を推奨)
バックアップドメインコントローラ	不可能
Windows 95/98 互換機能	可能
ローカルマスタブラウザ	可能
ローカルバックアップブラウザ	不可能
ドメインマスタブラウザ	可能
プライマリWINSサーバ	可能
セカンダリWINSサーバ	不可能

Using Samba