今回も前回に引き続いてSambaの仕組みと設定項目について解説する。SambaはWindowsのファイル／プリントサーバ機能（Windowsネットワーク）をLinuxなどのUnix系OS上に実現したもので，ブラウジング，ユーザ認証，ファイル／プリントサービス，NETBIOSといったWindowsネットワークの基本構成要素を一通り備えている。前回はその構成要素の一つ，ブラウジングに関する話題を取り上げた。ブラウジングはネットワーク上のサーバを一覧表示するための仕組みで，これでどんなサーバがネットワークにあるのかがわかる。これがわかれば，その中から自分が使うサーバを選んで，そこに接続すればよい。この接続から後の動作が今回の話題だ。

ユーザレベルとシェアレベル

　Windowsネットワークではサーバに接続する際に，まずユーザを確認するユーザ認証のステップがある。これには二つのタイプがある。
　一つは，接続してくるユーザの一人一人を識別し，ユーザ毎に誰がどのファイルやプリンタにアクセスできるのかを個別に設定するタイプだ。これをWindowsネットワークではユーザレベルのセキュリティと呼んでいる。Windows NTサーバがこれに相当する。
　もう一つはシェアレベルというもので，個々のユーザを識別しないタイプだ。こちらは公開したディレクトリやプリンタに誰でもアクセスできる。ディレクトリやプリンタを公開するときにパスワードを設定し，アクセスを制限することもできる。その場合は接続するときにパスワードを送り，それが一致するときだけ接続を許可するのである。このときパスワードを検査するだけで，ユーザが誰であるのかは問わない。Windows 9xのサーバ機能がこれに相当する。
　Sambaはこの両方のタイプに対応しており，表1のパラメータを設定によってどちらのタイプで動作するのか決める。Sambaはデフォルトでシェアレベルに設定されているので，そちらから説明しよう。

シェアレベルの設定

　シェアレベルで動作させるときは，[global]セクションで
  security = share
とパラメータを設定する。これだけだ。
　ただし，Windows 9xのシェアレベルとは動作の仕組みが異なる。Windows 9xには元々ユーザ個々に対してアクセス権限を設定するという概念がない。だからユーザが誰なのかを問わないシェアレベルという考え方が自然なのだが，LinuxはWindows 9xとは違って，ディレクトリやファイルにはユーザ別にアクセス権限が設定されている。そのため，ユーザが誰なのかがわからないとアクセス権限が決まらず，ディレクトリやファイルにアクセスできない。つまり，シェアレベルのような方法でのアクセスは本来不可能なのである。そこでSambaはアクセスしてきたクライアントにユーザ名を割り当て，そのユーザの権限でディレクトリやファイルにアクセスするようにする。
　このユーザ名割り当てやアクセス権限の設定は公開ディレクトリの設定と一緒に行うので，後でまとめて説明しよう。また，パスワードを暗号化も後で説明する。

ユーザ認証の概要

　Sambaはユーザレベルで動作させることもできる。Sambaにとってはその方が自然な方法といえる。
　ユーザレベルで動作させるときは，ユーザ名とパスワードによって個々のユーザを識別し，それが本人であることを確認する。Sambaにはその確認方法が二つ用意されている。ユーザ名とパスワードを自分自身で確認する方法と，他のサーバに確認を依頼する方法の二つだ。また，パスワードをクライアントからサーバに送信するとき，暗号化する場合とそうでない場合の二つがある。これを組み合わせると図1のようになる。

Sambaサーバ自身でパスワード照合

　ユーザ名とパスワードを自分で確認する場合は，[global]セクションで
　security = user
とパラメータを設定する。そしてパスワード暗号化の有無を設定する。
　encrypt passwords = no
と設定すればパスワードは暗号化しない。こうすると，クライアントから送られてきたユーザ名とパスワードをLinuxのOSに登録されたものと照合する。
　Linuxにはパスワードを登録したり確認する方法がいくつかある。passwdファイルに直接登録する方法，シャドウパスワードファイルに登録する方法，NIS（Network Information System）を使う方法などだ。それぞれ別々に説明すると煩雑になるので，以下ではpasswdファイルに直接登録されているものとして話を進める。すると，Sambaクライアントから送られたパスワードはpasswdファイルのパスワードと照合される。
　この方法は簡単で設定も楽なのだが問題がある。暗号化していないパスワードがネットワークに流れてしまい，盗聴される危険性があるという点が一つ。これだけでも問題だが，クライアントのバージョンによっては接続できないことがあるという別の問題もある。
　以前のWindowsネットワークではパスワードは暗号化しても暗号化しなくてもどちらでもよかった。通信する前に相手の状況を調べて，相手が暗号化に対応していれば暗号化し，対応していなければ暗号化せずにパスワードを送信するようになっていたのである。ところが，Windows NT 4.0のサービスパック3以後，あるいはWindows 98ではパスワードを暗号化せずに送ることを止めてしまった。そのため，Samba側で暗号化パスワードを有効にしないとパスワードを確認できなくなってしまったのである。
　この問題を解決する方法は二つある。一つはWindows側のレジストリを変更してパスワードを暗号化せずに送る方法だ（図2）。パスワードを盗聴される危険性はあるが，接続できないという事態は回避される。現時点では，パスワードを暗号化するとSamba側の設定が面倒になるため，この方法を採用する例が多いようだ。ただ，クライアント全部のレジストリを変更しないといけないので，クライアントの台数が多いと手間がかかる。

パスワードの暗号化

　もう一つの方法はSamba側で暗号化パスワードを有効にする方法だ。こちらの方は，まず，
　encrypt passwords = yes
として暗号化パスワード機能を有効にして，そして，次のように暗号化したパスワードを登録しておくファイルを指定する。
　smb passwd file = /etc/smbpasswd
このファイルはデフォルトのセットアップでは作られないので，自分で作り，そこに暗号化したパスワードを登録しなければいけない。その操作は図3にある。これで暗号化パスワードが有効になる。なお，passwdファイルにパスワードが登録されているのに，それを使わないのは次の理由があるからだ。
　Linuxはpasswdファイルなどにパスワードを登録するとき，パスワードをそのまま登録せずに一種の暗号化処理を施してから登録する。ところが，この暗号化処理は普通の暗号化とは違って，元のパスワードには戻せないように工夫されている。だから，パスワードを照合するときは，入力したパスワードを暗号化処理してから登録されている暗号化処理済みパスワードと照合する。暗号化処理されたパスワードを元に戻してから照合するのではない。このような照合方法を採用するのは，passwdファイルを見ても元のパスワードがわからないようにするためだ。
　Windowsネットワークのパスワード暗号処理もLinuxと同様に元に戻せないものであり，暗号化の方式が異なる。暗号化方式が違うので，元のパスワードが同じでも暗号化した後は違うものになってしまう。そのため，passwdファイルなどに登録されているパスワードとは照合できない。暗号化したパスワードを元に戻せれば，一度元に戻して再度暗号処理を施せば照合可能になるが，どちらのパスワードも元に戻せないようになっており，元のパスワードは知りようがない。だから，元のパスワードが同じものであっても別々に登録せざるを得ないのである（図4）。

暗号化パスワードの自動登録

　これでSambaを暗号化パスワードに対応させることができるが，図3のようにsmbpasswdコマンドを使って全員のパスワードを登録する方法は手間がかかる。そこで，自動的にsmbpasswdファイルに暗号化したパスワードを登録する方法も用意されている。
　その方法は，パスワードを暗号化しない状態で運用しているものを，暗号化パスワード対応に移行することを想定したもので，まず，暗号化しないパスワードで一度Sambaサーバに接続し，そのとき使ったパスワードを暗号化してsmbpasswdファイルに登録するものだ。これを実行するときは，次のようにパラメータを設定する。
　encrypt passwords = no
　smb passwd file = /etc/smbpasswd
　update encrypted = yes
この3番目の行が接続時に使ったパスワードをsmbpasswdファイルの登録するためのものだ。もちろん事前にsmbpasswdファイルは用意しておくが，そこにパスワードを登録する必要はない。図3(a)の方法でsmbpasswdファイルを作るだけでよい。1番目の行でパスワードを暗号化しないように設定する点にも注意しよう。それから，図2の要領でクライアント側もパスワードを暗号化しないように設定しないといけない。
　これで，全員がSambaサーバへの接続動作を済ませ，smbpasswdファイルに暗号化パスワードが登録されたら，
　encrypt passwords = yes
　update encrypted = no
と設定を変更して暗号化パスワードを受け付けるように変更する。このとき。クライアント側のレジストリも暗号化するように設定し直した方がいいのだが，そちらは必須ではない。クライアントはパスワード送信前にサーバが暗号化に対応しているか否かを調べ，Samba側で暗号化パスワードに対応していれば，クライアントもパスワードを暗号化するようになるからだ。
　これでsmbpasswdファイルに暗号化パスワードを登録する手間は省けるが，その後パスワードを変更する作業までは自動化できない。smbpasswdコマンドでの変更が必要だ。
　どの方法を使ったとしても，Sambaサーバ自身で暗号化パスワードを照合する方法はある程度の手間がかかるので，それと安全性を計りにかけて暗号化するべきか否かを考えなくてはいけない。

smbpasswdとpasswdファイルの同期

（後日追加予定）

シェアレベルでも暗号パスワードには注意

　暗号化パスワードはシェアレベルでも使えるが注意点がある。本来，シェアレベルはユーザを匿名として扱うため，ユーザ名やパスワードを照合する必要はない。公開ディレクトリ／プリンタにパスワードを設定しなければ，暗号化パスワードとは無縁のはずである。ところが，ブラウジングで問題が起こる。
　［ネットワークコンピュータ］アイコンを開くと，ネットワーク上のサーバが一覧表示されるが，この情報はマスタブラウザまたはバックアップブラウザから入手することになっている（前月号参照）。実際には，まずマスタブラウザに接続動作を実行してからバックアップブラウザの所在を問合せ，そこからサーバ一覧情報を入手するのだが，その接続動作が失敗するのだ。SMB/CIFSプロトコルは接続時に相手がどのような機能に対応しているのかを調べるネゴシエーションという動作を行うのだが，このとき，クライアント側の暗号化が必須で，マスタブラウザやバックアップブラウザが暗号化パスワードに対応していないと，ネゴシエーションに失敗して接続できなくなるからである。その結果，サーバ一覧情報を入手できず，ネットワーク上のサーバが見えなくなる。
　この場合は，どのマシンがマスタブラウザやバックアップブラウザとして動作しているのかを探し，そのマシンで
　encrypt passwords = yes
としてSambaの暗号化パスワードを有効にすればよい。これでネゴシエーションに成功するので問題は解決する。ユーザ名とパスワードの照合は行わないので，smbpasswdファイルを設定する必要はない。ただ，マスタブラウザやバックアップブラウザはその時々で変わる可能性があるから，実際にはマスタブラウザやバックアップブラウザになる可能性のあるマシン全部にこの設定を行う必要がある。
　クライアント側で図2のように設定して暗号化しないパスワードを送るように設定する方法もあるが，この場合はユーザレベルと違って，smbpasswdを設定する必要がないので，Sambaサーバ側を暗号化した方が手間はかからないだろう。なお，Windows NTサーバは元々暗号化に対応しているので，それがネットワーク上にある場合は，Windows NTがマスタブラウザやバックアップブラウザになるように設定する，という方法もある。

サーバレベルセキュリティ

　Sambaにはユーザ名とパスワードを自分で照合せずに，他のサーバに照合依頼する方法も用意されている。この方法には，ドメインに所属しないサーバが使う方法と，ドメイン内のメンバサーバがドメインコントローラにパスワード照合を依頼するときに使う方法の二つがあり，それぞれ設定項目が異なる。まず，前者の方法から説明しよう。
　この記事では，この方法を仮にサーバレベルセキュリティを呼ぶことにしよう。その実態は，クライアントから受け取ったユーザ名とパスワードをそのままパスワード照合依頼先のサーバに転送し，そこでユーザ名とパスワードを照合するものだ。つまり，受け取ったものをそっくりそのまま依頼先に転送し，依頼先から返ってきた照合結果をそのまま返すのである。ユーザ名とパスワードはSambaサーバを素通りするだけだと思えばよい。
　この方法を使うときは，図5のようにsmb.confファイルのパラメータを設定する。依頼先のサーバはWindows NTサーバでもSmabaサーバでもよい。NTサーバの場合はドメインコントローラでも，ドメインに所属しないワークグループのサーバでもよい。暗号化もどちらでもよい。暗号化の如何に関わらず，パスワードはそのまま依頼先のサーバに転送され，そこで暗号処理を施すので，Sambaサーバはパスワードの暗号化について関知する必要がないのだ。ただし，依頼先のサーバの暗号化対応はクライアントの対応状況に合わせなければいけない。つまり，クライアントが暗号化を要求するのであれば暗号化に対応する必要がある。なお，Windows NTサーバは両方に対応しているので，NTサーバを依頼先に指定する場合は，クライアント側の暗号化はどちらでもよい。
　依頼先のサーバを設定したら，passwdファイルにユーザを登録する。これで設定は終わりだ。
　smbpasswdファイルを使って暗号化パスワードに対応する方法は，最初にパスワードを設定したり，途中でパスワードを変更するときに手間がかかる。何らかの形でサーバの管理者が変更作業に関わらないといけないからだ。しかし，サーバレベルセキュリティを使えば，パスワード照合依頼先のサーバで一括管理するだけでよく，Sambaサーバでパスワードを管理する必要がなくなる。Sambaサーバを複数設置するような場合にはこの方法がよいだろう。また，図6のようにパスワード照合依頼先のサーバがドメインコントローラなら，ドメインにログインしている状態でクライアント側からパスワード変更操作を行えばサーバ側のパスワードが変更される。これなら，パスワードを変更するのに管理者の手を借りる必要はなくなる。
　なお，Sambaは接続してきたユーザにLinux上のユーザ名を割り当てるため，新規ユーザを登録したりユーザ名を変更する場合にはLinux側でユーザ名を登録したり，ユーザ名を変更する作業が必要である。この点はsmbpasswdファイルに暗号パスワードを登録する方法と変わりはない。もし，Linuxにユーザが登録されていなければ，Sambaクライアントはゲスト扱いになる。

ドメインへの対応

　パスワード照合を他のサーバに依頼する方法はもう一つある。ドメイン内のメンバサーバがドメインコントローラにパスワード照合を依頼するのと同じ方法だ。ここではこれを仮にドメインレベルセキュリティと呼ぶことにしよう。
　ドメインレベルの動作は見かけ上サーバレベルとよく似ている。自分ではパスワードを検査せず，依頼先のサーバが返す結果を頼りにパスワードを判定する基本的な仕組みに何も違いはないからだ。しかし，ドメインレベルとサーバレベルではパスワード照合依頼先サーバとの間で交換する情報の内容が違う。その違いは後で説明することにして，まずは，設定方法を説明しよう。
　これまでの設定はsmb.confファイルにパラメータを記述すれば済んだが，ドメインレベルの場合はsmb.confファイルのパラメータ設定だけでなく，いくつかのステップを踏まなくてはならない。各ステップの操作は図7にあるものだが，これが終わったらSambaサーバをリスタートすれば，Sambaサーバはドメインのメンバサーバとして動作するようになる。
　なお，図7(c)の4行目で暗号化パスワードを有効にしているが，これがなくても照合依頼時にSambaサーバがパスワードを暗号化してくれる。ただ，そうすると接続時にユーザ名とパスワードの入力を促すウインドウが現われる。そもそも，ドメインを使うメリットは，一度ユーザ名とパスワードを入力してログオン操作を行えばドメイン内のサーバにはログオン操作なしでアクセスできるシングルログオンを実現できることにある。それがサーバに接続するたびにユーザ名とパスワード入力が必要ではドメインを使うメリットがないので，暗号化パスワードは有効にしておくべきだろう。
　これでSambaサーバがドメインのメンバサーバとして動作する。Sambaはドメインコントローラに登録されているユーザ情報を利用するので，Samba側でパスワードを管理する必要はない。ただ，サーバレベルと同様にLinux側にユーザ名を登録しておかないとユーザを割り当てできないので，ユーザ名を変更したり新たなユーザを登録する場合はLinux側でユーザ登録変更作業が必要になる。

サーバレベルとドメインレベルの違い

　ドメインレベルとサーバレベルはよく似ているし，実際の利用効果も大差ない。
　使用上の違いがあるとすれば，事前にログオンを必要とするか否かといった違いだけだろう。ドメインレベルの場合，サーバに接続するときに事前にドメインにログオンしておく必要がある。ドメインに所属するサーバは，ドメインへのログオンを済ませていないクライアントからの接続を拒否するからだ。
　これに対して，サーバレベルの場合はそういった事前のログオンは必要ない。Windowsはマシンを起動したときにログオン画面が現われ，ログオンを促すことになっているが，ドメインを使わない場合は，そのログオン操作はローカルなマシンに対してのログオンであり，サーバにログオンしているわけではない。サーバに接続するときに，ローカルでログオン操作を済ませていれば，その時に入力したユーザ名とパスワードを自動的にサーバに送ってくれるというだけだ。そのユーザ名とパスワードがサーバ側で有効ならそのまま接続が許可されるが，無効ならクライアント側にログオン画面が現われ，ユーザ名とパスワード入力を促すだけである。そこで，サーバに接続するためのユーザ名とパスワードを入力すればサーバに接続できるのである。

信頼するドメインに対するパスワード照合依頼

　ドメインへのログオン以外に違いはないのだろうか。その疑問に答えるには，パスワードを照合するときにネットワークに流れる情報，つまりプロトコルに違いまで掘り下げる必要がある。プロトコルにはパスワードの暗号化が絡んでくるので，まず，パスワード暗号化の仕組みから説明する。
　普通，暗号化というと暗号キーを使って元のデータに暗号処理を施すことと考えがちだが，Windowsのパスワード暗号化はそうではない。その基本的な考え方は，まず，サーバ側から乱数を元に生成した小さなデータ（これをチャレンジという）を送る。そして，クライアント側はパスワードを元にして作り出した暗号鍵によってこのチャレンジを暗号化する。パスワードを暗号化するのではなく，パスワードが暗号化の鍵になるのだ。
　こうする理由は，単純な暗号化には危険があるからだ。単純にパスワードを暗号化すると，その結果はいつも同じになってしまう。すると，暗号化したパスワードを盗聴して，それをサーバに送ればパスワードの照合に合格する。元のパスワードを知らなくてもパスワードが破られてしまうのだ。この考え方に基づく攻撃をリプレイ攻撃といい，LANのように簡単に盗聴できる環境では，その対策を講じないと暗号化の意味がない。そこで暗号化した結果が毎回同じ値にならないように工夫する必要がある。それがチャレンジの役割だ。チャレンジは乱数などを元にして生成する小さなデータで，これを暗号化すればその結果は毎回違ったものになる。そうすれば，盗聴したものは役に立たなくなり危険はなくなる。
　このチャレンジを使う方法をチャレンジレスポンス方式といい，Windows以外でも一般的に用いられている。そのやり取りを図で表すと，図8のようになる。
　サーバレベルセキュリティではこれが図9(a)のようになる。つまり，チャレンジと暗号化したパスワード情報は接続先のサーバを素通りしてパスワード照合依頼先のサーバとクライアントの間を行き来する。一方，ドメインレベルの場合は，接続先のサーバがチャレンジを生成する（図9(b)）。それと暗号化したパスワードを一緒にパスワード照合サーバに送って照合を依頼する。パスワードを照合するサーバにはパスワードを元に生成した暗号鍵が登録されているから，その鍵で送られてきたチェレンジを暗号化し，一緒に送られてきた暗号化したチャレンジと照合すればパスワードが正しいかどうか確認できるのである。
　ドメインの場合には，ここでパスワード照合先のドメインコントローラに信頼関係が設定されている可能性がある。そして，ログオンしてきたユーザが信頼するドメインのユーザであれば，ドメインコントローラは信頼するドメインのドメインコントローラにパスワード照合を転送する（図9(c)）。これで信頼するドメインに登録されているユーザのパスワード照合が可能になり，そのユーザがサーバに接続できるようになる。ドメインの信頼関係の考え方は一見複雑に見えるが，その実態はこうしたパスワード照合とその転送の仕組みが内部で動いているに過ぎないのだ。
　これが，パスワード照合時の大まかな流れだが，もう一つ知っておくべきことがある。クライアントがドメインにログオンしているときとそうでないときでは，やり取りするデータの内容に違いがあるのだ。このパスワードのやり取りのときに，ドメインにログインしているWindowsネットワークのクライアントは，そのドメイン名をユーザ名と一緒に送る。これで，ユーザがどのドメインに所属するのかが分かる。信頼関係を設定しているときはそのドメイン名を元にパスワード照合先のPDCを決める。自分のドメインであれば自分でパスワードを照合し，信頼するドメインであればそこに転送するのだ。ところが，ドメインにログオンしていないときはドメイン名の代わりに自分のコンピュータ名を送る。ドメインコントローラはドメインにログオンしていないユーザのパスワード照合は拒否するので，ドメインでのパスワード照合は失敗に終わる。ドメインに所属するサーバがログオンしていないユーザの接続を拒否する動作はこうなっているのだ。
　Sambaサーバがサーバレベルに設定されている場合でもクライアントから送るデータの内容は同じであり，クライアントがドメインにログオンしていればドメイン名を送る。すると，Sambaサーバを素通りして，その先でドメインに所属するユーザとしてパスワードを照合する。パスワードが正しければその照合は成功する。結果的にはドメインレベルと同じことになる（図9(d)）。照合先がPDCで信頼関係が設定されていればそちらに転送される点も同じなので，ますますサーバレベルとドメインレベルの違いはなくなってくる。それが，サーバレベルとドメインレベルの実態だ。
　このように，サーバレベルとドメインレベルに差が見られないのは，ドメインレベルがSamba2.0で登場した新しい機能で，まだ発展途上にあるためだ。ドメインレベルは，今はまだドメイン内のメンバサーバとしてしか機能しないが，将来ドメインコントローラと同等の機能を持つようになる予定であり，そのときは，サーバレベルとは違うものになる。

ログオンスクリプト

（後日追加予定）

ユーザ名の割り当て

　パスワードの確認が終わると，Sambaサーバはアクセスしてきたクライアントにユーザを割り当てる。
　パスワードを確認するときはユーザ名も一緒に確認するが，そのユーザはLinuxに登録されているユーザだとは限らない。Sambaが自分自身でpasswdファイルと照合する場合は，Linuxのユーザだと見なすこともできるが，他のサーバにパスワード照合を依頼する場合は，そういうわけにはいかない。他のサーバでパスワードを確認できたとしても，それはLinux側のOSに登録されているユーザとは何の関係もないからだ。シェアレベルのように，ユーザ名がない場合もある。LinuxはOSに登録されたユーザでなければ何の権限も与えられないので，このままではSambaのユーザはファイルやプリンタにアクセスできない。だから，SambaのユーザにLinuxのユーザを割り当てることが必要になる。
　この割り当てはパスワードと一緒に送られてきたユーザ名が元になる。そのユーザ名と同じ名前のユーザがOSに登録されていれば，そのユーザが割り当てられる。つまり，Sambaクライアントから送信されるファイルやプリンタに対する操作はそのユーザが行っているものだと見なすのだ。その結果，そのユーザの権限でファイルにアクセスできるし，ファイルやディレクトリを作れば，そのユーザが作成者になる。
　ユーザ名がLinuxに登録されていない場合にはゲスト扱いになり，そのユーザにはguest accountというパラメータで設定されたユーザが割り当てられる。たとえば
　guest account = user1
というように設定すればゲストユーザにはuser1という名前が割り当てられる。このパラメータが設定されていなければ，デフォルト値であるnobodyというユーザが割り当てられる。
　強制的に別の名前のユーザを割り当てる方法もある。割り当てるユーザを設定したファイルを用意し，そのファイルをusername mapパラメータで指定する方法だ。（図10）
　これがユーザ割り当ての原則だが，ドメインが信頼関係を設定し，信頼するドメインに同じ名前のユーザが登録されている場合は要注意だ。Windowsではドメインとユーザ名を組み合わせて個々のユーザを識別する。だから，信頼するドメインに同じユーザが登録されていたとしても，ドメイン名が違えば別々のユーザとして扱われる。しかし，Linuxにはドメインという考え方はなく，ユーザ名だけでユーザを識別する。そのため，ドメインが違ってもユーザ名が同じなら同じユーザと見なされてしまうのだ。

シェアレベルでのユーザ割り当て

　シェアレベルでクライアントがユーザ名を送ってこない場合は，ゲスト扱いにしてguest accountでユーザ名を割り当てることができるが，usernameというパラメータを使ってユーザ名割り当て方法もある。
　このパラメータの設定は，
　username = user1, user2
というようにLinuxに登録されているユーザ名を複数列記する。そして，仮にuser1とuser2にそれぞれpass1，pass2というパスワードが登録されているものとしよう。すると，ユーザが入力したパスワードがpass1ならuser1というユーザ名が割り当てられ，pass2だったらuser2が割り当てられる。パスワードがどれにも一致しない場合は接続は拒否される。
　usernameパラメータは，通常，公開ディレクトリを設定するセクションの中で設定する。セクションごとに別のユーザを列記してもよいので，公開ディレクトリごとに別々のユーザを割り当てることもできる。これは公開ディレクトリごとに別々のパスワードを設定していることにもなる。ある公開ディレクトリではuser1とuser2のパスワードが受け付けられ，別の公開ディレクトリではuser3のパスワードが受け付けられるといった具合だ。
　Windowsのシェアレベルでは，読み込みだけ許すパスワード，読み書き両方を許すパスワードというように権限に応じて違うパスワードを設定できる。これと同じことも実現できる。
　Linuxはユーザを，ディレクトリ／ファイルの所有者，ディレクトリ／ファイルに設定されているグループに所属するユーザ，それ以外のユーザ，の3種類に分け，それぞれにアクセス権限を設定する（図11）。Sambaのシェアレベルのアクセス権もこの仕組みをそのまま流用するから，この仕組みに則ってユーザのアクセス権限を設定すればよいのだ。たとえば，pass1というパスワードは読み書き両方を許可し，pass2は読み込みだけ許可するように設定するものとしよう。その場合は，まず，公開ディレクトリの所有者をuser1にし，user2を公開ディレクトリのグループに所属させる。そして，図12のように所有者には読み書き両方を許可し，グループには読み込みだけを許可するのである。これで，pass1というパスワードを入力したユーザはuser1，つまり所有者になるので読み書き両方が許可され，pass2というパスワードを入力したユーザはuser2，つまりグループのユーザとなり，読み込みだけが許可される。Windowsと違って設定が直接的ではないから，慣れないうちは面倒かもしれない。
　シェアレベルのサーバに対してユーザ名／パスワードが送られてくる場合もある。クライアントがログオン操作を済ませている場合などだ。その場合，パスワードの照合に成功し，ユーザ名がLinuxに登録されていれば，そのユーザ名が割り当てられる。シェアレベルであってもユーザ名が送られてくればその名前のユーザを割り当てるのである。ただし，公開ディレクトリでpublic = yesが設定されている場合は例外で，そのディレクトリにアクセスするときはguest accountに設定したユーザが割り当てられる。

ディレクトリの公開とアクセス権

　SambaはLinuxの全ディレクトリをクライアントに公開するのではなく，設定したディレクトリだけを公開する。それは[]で囲んだセクションで設定する。図13に典型的な例をいくつかあげておく。ディレクトリ公開に関する設定はそれほど難しくないのでこの例で基本的な考え方はわかるだろう。表2にもパラメータの説明があるのでそれも参考にして欲しい。
　公開するディレクトリのアクセス権設定は，パスワードでアクセス権を変える例で説明したとおりだ。つまり，ユーザ認証のときに割り当てられたユーザとファイルやディレクトリに設定されているモードによってアクセス権が決まる。
　このモードはファイルやディレクトリを作成するときに設定される。Linuxに直接ログインしたユーザがファイルやディレクトリを作る場合はumaskの値によって決まるが，Sambaのクライアントの場合はumaskは適用されない。create maskあるいはdirectory maskというパラメータの設定値でモードが決まる。もちろんこの値は途中で変更することもできるが，それはLinux側でコマンドなどと使って変更する場合に限られる。Sambaクライアントからは変更できない。

ファイル／ディレクトリ名と属性

　LinuxとWindowsではファイル名の扱いに違いがある。まず，ファイル名の長さが違う。Linuxのファイル名は最大126文字だ。本来，Windowsは9xで最大246文字，NTだと最大240文字まで扱えるが，Sambaを使う場合はLinuxサーバに127文字を超える長いファイル名は使えない。
　Linuxは英文字の大文字と小文字を別の文字として扱うがWindowsは同じ文字だと見なす。これも問題だ。そのため，大文字と小文字の扱いをパラメータで設定できるようになっている（表3）。
　また，次のように漢字コードを設定すればファイル／ディレクトリ名に漢字を使うこともできる。
　client code page = 932
　coding system = EUC
しかし，半角カタカナの使用は要注意だ。Linuxでは半角カタカナは原則として使わないことになっており，Sambaクライアントがファイル名やディレクトリ名に半角カタカナを使うとLinux側で文字化けを起こす（図14）。ただ，この文字が化けはLinuxのコンソールプログラムなどが半角カタカナを表示できないだけで，Linuxのディレクトリには半角カタカナの文字コードが記録される。だから，Sambaクライアントは半角カタカナを正しく扱える。Linux側でそのファイル／ディレクトリに触らなければ問題にはならない。また，Linux側でSambaのファイル／ディレクトリを触らないのであれば，英語版のLinuxサーバでファイル／ディレクトリ名に漢字コードを使ってもかまわない。Linuxカーネル自身は英語版も日本語版も変わりはなく，両方とも漢字コードを正しく扱えるように作られているからだ。
　Windowsのファイルには隠し属性，システム属性，アーカイブ属性といった属性を設定できるが，Linuxのファイルにはこれに相当する属性はない。そこで，Linux側のファイル属性情報をこの属性に割り当てるパラメータもある。

プリンタの設定

　Sambaのプリントサーバは図15のような仕組みで動く。
　クライアントから印刷データをSambaサーバに送るまでの手順はファイルサーバにファイルを書き込むときと似ている。ブラウジング，ユーザ認証，ユーザの割り当て，アクセスチェックといった手順を踏み，クライアントが送ってきた印刷データをファイルにまとめてスプールディレクトリに書き込むのだ。デフォルト設定では，Sambaのスプールは誰でも書き込めるようにアクセス権が設定されるので，セクションの設定でguest okをyesに設定しておけば，誰でもスプールに印刷データを書き込める。使用制限を設ける場合は，セクション内でvalid usersによってユーザを制限すればよい。
　スプールに印刷データを書き込んだら，それを印刷するようLinuxのプリントシステムに依頼する。この依頼はLinuxのプリントシステムコマンドを呼び出して行う。Sambaの役割はここまでだ。この後はOSのプリントシステムの仕事である。
　Unix系OSのプリントシステムはその系統によって異なり，印刷する仕組みが違う。Sambaはその系統の違いをprintingパラメータで設定することになっている。LinuxはBSD Unixのプリントシステムを採用しているので，bsdと設定する。これで，通常使うコマンドが設定される。印刷の依頼はlprというコマンドを呼び出すことになるだろう。そうすれば，lprコマンドがOSのスプールに印刷データを移してくれる。その後，lpdデーモンがそこから印刷データを取り出して，プリンタに送り，紙に印刷される。
　この仕組みを図にすると図15のようになるので，プリントサーバの設定はこの図の構成要素が正しく動くように設定すればよいことになる。主なポイントは使うプリンタの名前，Sambaの印刷スプールの位置，Linuxへの印刷の依頼方法，の三つである。具体的な設定は図16の例と表4のパラメータ説明でわかるだろう。もし，うまく印刷できない場合は次の点を調べてみるとよい。
　最初のチェックポイントは，印刷データがSambaのスプールに正しく書かれているどうかだ。printingパラメータの設定はプリントシステムの種類を指定するだけで，コマンドの設定は用意されているデフォルト値が採用される。その状態では，Linuxのプリントシステムに印刷を依頼した後，Sambaのスプールから印刷データを削除するように設定されているはずだ。それを印刷後消さないように設定を変更すればスプールに書き込んだ内容を調べることができる。そのためにはprint commandパラメータを使う。このパラメータは印刷を依頼するときに実際に呼び出すコマンドの詳細を指定するものだ。printing=bsdと設定した場合は，これが
　lpr -r -P%p %s
と設定されているはずであり，-rが印刷後の削除を表すオプションになっている。だから，この-rを取り去ればよい。これで，印刷データがスプールディレクトリに残るので，それが正しいかどうかを確認すれば，スプールに書き込む前に問題があるのかどうかがわかる。
　そこまでに異常がなければ，その後はLinuxのプリントシステムの問題になるので，lprコマンドなどを手動で操作してLinuxのプリントシステムに異常がないかどうか調べればよい。

不向きな用途への利用は失敗の元

　2回にわたりSambaの仕組みと設定について説明したが，Linux／Sambaは費用削減に効果はあるものの，使用上いくつかの注意点があることも否めない。特に，ユーザ個別にファイルのアクセス権を設定するような使い方は要注意だ。使い方次第では運用管理コストがWindows NTサーバの購入費用を上回り，Sambaの方が高くつくこともあるだろう。コストだけでなく，使い物にならない可能性だってある。安いというだけでLinux／Sambaの導入を決めるのは危険だ。