[Chapter 6] 6.3 認証とセキュリティ
Date: 1999-11-05T21:33:44Z

| ## Using Samba Robert Eckstein, David Collier-Brown, Peter Kelly 共著 第一版 1999 年 11 月 1-56592-449-5, 注文番号: 4495 416 ページ, 34.95 ドル ハードコピー版(英語)を購入する 目次

| Chapter 6 ユーザ、セキュリティ、ドメイン |

> ## 6.3 認証とセキュリティ

> ここでは、Samba がどのようにしてユーザを認証するのかについて説明する。ユーザが (ゲストアクセスの許可されていない) 共有に対して接続するには、パスワードを送信する必要がある。Samba がパスワードをどのように扱うか、すなわち Samba がユーザ認証をどのように行うかは、`security` 設定オプションで設定される。現在 Samba には share, user, server, domainという 4 つのセキュリティレベルがある。

> 共有 (share) レベルのセキュリティ

>   ワークグループ内の各共有には一つ以上のパスワードがつけられる。共有のパスワードを知っているユーザは誰でもその共有にアクセスできる。

> ユーザ (user) レベルのセキュリティ

>   ワークグループ内の各共有は、指定されたユーザだけがアクセス可能なように設定される。最初の tree connection の時点で、Samba サーバはユーザ名とパスワードを確認してから共有へのアクセスを許可する。

> サーバ (server) レベルのセキュリティ

>   これはユーザレベルのセキュリティと同等であるが、Samba サーバは共有へのアクセスを許可する前に、別の SMB サーバを利用してユーザ名とそのパスワードを認証する。

> ドメイン (domain) レベルのセキュリティ

>   Samba は Windows ドメインのメンバとなり、認証を行う際にドメインのプライマリドメインコントローラ(PDC)を利用する。認証が行われると、ユーザは適切なアクセス権を持っていることを示す特別なトークンを受け取る。このトークンを用いると、ユーザがドメイン内の別の共有に接続する度に、PDCがそのパスワードを認証し直す必要はなくなる。

> このセキュリティポリシーは、 表 6.3に示したように、グローバルな `security` オプションで設定される。

> 表 6.3: セキュリティオプション
> オプション | パラメータ | 機能 | デフォルト | 範囲
> --- | --- | --- | --- | ---
> `security` | `domain`, `server`, `share`, or `user` | Samba サーバが利用するセキュリティのタイプを指定する | `user` (Samba 2.0)、`share` (Samba 1.9) | グローバル

> ### 6.3.1 共有レベルのセキュリティ

> 共有レベルのセキュリティを用いると、各共有に対して一つ以上のパスワードが割り当てられる。他のセキュリティモードとの違いとして、正しいパスワードを知ってさえいれば、誰でも共有にアクセスでききてしまう点が挙げられる。共有には複数のパスワードを割り当てることもできる。例えばあるパスワードでは読み込みアクセスを与え、別のものでは読み書きアクセスを与えるようにできる。この認証の安全性は、認証されるべきでないユーザが共有のパスワードを発見しないかどうかにかかっている。

> OS/2 と Window 95/98 は自身のリソースの公開にあたって、共有レベルのセキュリティをサポートする。Windows 95/98 で共有レベルのセキュリティを設定するには、まずコントロールパネルの[ネットワーク]にある[アクセス制御]タブを用いて共有レベルのセキュリティを有効にする。続いて 図 6.1のように 「共有レベルでアクセスを制御する」というラジオボタンを選択し (この際「ユーザー レベルでアクセス制御する」のラジオボタンは非選択になる)、OK ボタンを押す (nakano 注: デフォルトは「共有レベル」の方になっているはずです)。

> #### 図 6.1: Windows マシンで共有レベルのセキュリティを選択する

> 次にハードディスクやCD-ROM等のリソースを右クリックして、メニューからプロパティを選択する。するとリソースのプロパティダイアログボックスが表示される。ここでダイアログボックスの上部にある「共有」タブを選択し、リソースの共有を有効にする。ここで共有するリソースを読み込み専用にするか、読み書き可能にするか、あるいは両方にするかといった方式を設定する。どの方式を用いるかはパスワードの設定の仕方による。

> このセキュリティモデルはSambaとは相性が悪いのではないかと思うかもしれないが、その考えはたぶん正しい。実のところ、Sambaの設定ファイルで`security` `=` `share` オプションを設定しても、結局Sambaは認証の過程でシステムのパスワードファイルからユーザ名とパスワードとの組を利用することになる。詳しく説明すると、共有レベルのセキュリティを用いている場合にクライアントからの接続要求があった場合、Sambaは以下のように処理を行う:

> 1. 接続要求があると、Sambaはパスワードと(もし送信されていたら)クライアントのユーザ名を受信する。

> 2. 共有が `guest` `only`の時は、ユーザはその共有に`guest` `account` パラメータで指定されたユーザとしてアクセスする権限を直ちに獲得する。パスワードのチェックは行われない。

> 3. それ以外の場合、Sambaはまず渡されたユーザ名を「共有にアクセスできるユーザ」のリストに追加し、渡されたパスワードをそのユーザ名と組み合わせて認証を行う。認証に成功すると、そのユーザとして共有にアクセスする権限がSambaから与えられる。`revalidate` `=` `yes` オプションが共有に対して設定されていなければ、このユーザは認証を再度行う必要はない。

> 4. 認証に失敗すると、Samba はパスワードを先のリストに含まれるユーザそれぞれと組み合わせて認証を試みる。このリストは、過去の接続要求を通じて集められたものと、設定ファイルでその共有に対して指定されたユーザとからなる。パスワードがシステムのパスワードファイル (通常 /etc/passwd) のどのユーザ名とも合致しなかった場合、接続を試みたユーザは、そのユーザ名では共有へのアクセス権を獲得できない。

> 5. ただし、共有に対して `guest` `ok` か `public` オプションが設定されていると、そのユーザにはデフォルトが適用され、`guest` `account` オプションに設定されたユーザの権限でのアクセスが可能となる。

> 設定オプション `username` を用いると、共有レベルのセキュリティに対して最初に設定するユーザのリストを以下のように指定できる:

>     [global]
>     	security = share
>     [accounting1]
>     	path = /home/samba/accounting1
>     	guest ok = no
>     	writable = yes
>     	username = davecb, pkelly, andyo

> 上記では、ユーザが共有への接続を試みると、Samba は送信されたパスワードを 自身のリスト中の各ユーザのものと照合し、さらに `davecb`, `pkelly`, `andyo` といった各ユーザとも照合する。誰かのパスワードが合致すれば、接続は認証・許可される。さもなくば、その共有への接続は失敗する。

> #### 6.3.1.1 共有レベルのセキュリティオプション

> 表 6.4に、通常共有レベルのセキュリティと一緒に設定されるオプションを示す。

> 表 6.4: 共有レベルのアクセスオプション
> オプション | パラメータ | 機能 | デフォルト | 範囲
> --- | --- | --- | --- | ---
> `only user` | 真偽値 | `username` で指定されたユーザ名だけで認証を行うかどうかを設定する | `no` | 共有
> `username` (user または users) | 文字列(ユーザ名のリスト) | クライアントから送信されたパスワードをテストするユーザのリストを設定する | なし | 共有

> #### 6.3.1.2 only user

> この真偽値オプションを用いると、Sambaは `username` オプションで設定されたユーザだけに基づいて、共有レベルのセキュリティを用いた共有への接続を制御するようになる (通常は Samba が収集したユーザリストも用いられる)。このオプションのデフォルトは`no`である。以下のように、このオプションは共有ごとに変更することができる:

>     [global]
>         security = share
>     [data]
>         username = andy, peter, valerie
>         only user = yes

> #### 6.3.1.3 username

> このオプションは、Samba が接続を認証するさいにパスワードをテストするユーザのリストを指定する。これは、あるサービスへの接続許可を共有レベルのセキュリティで、すなわちあるパスワードのみで行う場合に用いられる。そのパスワードがある特定のユーザのパスワードにマッチすれば認証される:

>     [global]
>         security = share
>     [data]
>          username = andy, peter, terry

> Sambaサーバを共有レベルのセキュリティで運用したい場合以外は、このオプションを利用することは推奨できない。

> ### 6.3.2 ユーザレベルのセキュリティ

> Sambaとの相性が良いセキュリティのモードが ユーザレベルのセキュリティである。この方式を用いると、各共有はアクセス権のあるユーザ個々に対して提供される。ユーザが共有へ接続しようとすると、Samba は送信されてきたユーザ名とパスワードで認証を行い、そのユーザが設定ファイルでアクセスを許可されているかどうか、パスワードSambaサーバ上のパスワードデータベースのものとあっているか、を確かめる。本章で前述したように、ある特定の共有に対してアクセス可能なユーザを制限する方法の一つは `valid` `users` オプションをそれぞれの共有に設定することである:

>     [global]
>     	security = user
>     [accounting1]
>     	writable = yes
>     	valid users = bob, joe, sandy

> 列挙されたユーザは、入力したパスワードがサーバ上のパスワードデータベースに格納されているものと合致すれば、共有への接続が可能になる。最初の認証が成功すれば、ユーザは、`revalidate` `=` `yes` オプションが設定されていない限り、その共有へアクセスする際にパスワードを再度入力する必要はなくなる。

> パスワードを Samba サーバに送る際には暗号化、非暗号化のいずれの形式でも良い。ネットワーク上に両方の形式のシステムが存在する場合は、各ユーザのパスワードを、従来のアカウントデータベースと Samba の暗号化パスワードデータベースとの両方に格納しておく必要がある。このようにすれば、許可を得たユーザは、どのようなクライアントからでも共有へアクセスできるようになる。[1] ただし、セキュリティの観点からは非暗号化パスワードの利用をやめ、暗号化パスワードに移行することを推奨する。本章の Section 6.4 セクションで、暗号化パスワードおよび非暗号化パスワードをどのように利用するかについて説明している。

> > [1] Samba の設定ファイルで、クライアントのOSやマシン名を示す変数に応じて様々なオプションが選べるようになっている理由のひとつは、このように暗号化パスワードのクライアントと非暗号化パスワードのクライアントの両方がネットワーク上にあるから、である。

> ### 6.3.3 サーバレベルのセキュリティ

> サーバレベルのセキュリティは、ユーザレベルのセキュリティと似ている。ただしサーバレベルのセキュリティの場合、Sambaはパスワードの認証を別のSMBパスワードサーバ、通常は別のSambaサーバか、ネットワークでPDCとして機能しているWindows NT Serverに委任する。ただしこの場合も、Samba の提供する共有やその設定は smb.conf ファイル中で管理される。クライアントが特定の共有に対して接続を行なおうとすると、Sambaはユーザが共有に接続する権限があるかどうかを確かめる。続いてSambaは、規定のプロトコルでユーザ名とパスワードをSMBパスワードサーバに送信し、パスワードを認証する。パスワードが受け付けられた場合、クライアントとのセッションが開始される。 図 6.2 に図示したので参照してほしい。

> #### 図 6.2: サーバレベルのセキュリティを用いた場合の典型的なシステム

> グローバル設定オプションである `password` `server` を以下のように用いれば、サーバレベルのセキュリティで、別のパスワードサーバを用いるように Samba を設定できる:

>     [global]
>     	security = server
>     	password server = PHOENIX120 HYDRA134

> `password` `server` には複数のマシンを指定でき、この場合 Samba はサーバとの通信が行えなかった場合にリストを上から順にたどることになる。`password` `server` オプションに指定するサーバ名としては、DNS 名や IP アドレスでなく、NetBIOS 名を用いなければならない。またいずれかのサーバが送信したパスワードを拒否したら、コネクションはその時点で自動的に失敗し、Samba はそれ以上別のサーバと認証を行おうとはしない。

> ちょっと注意: このオプションを用いる場合でも、Samba サーバ上には依然としてユーザを識別するアカウントが必要である。これは UNIX が様々な操作を行う際に、ユーザ名を必要とするためである。これを実現する方法としては Samba サーバ上にアカウントは作成するが、システムパスワードファイル(例えば /etc/passwd ) 中の該当欄をアスタリスク(*)に置き換え、アカウントを無効にしてしまう方法がよいであろう。

> ### 6.3.4 ドメインレベルのセキュリティ

> ドメインレベルのセキュリティはサーバレベルのセキュリティと似ている。ただしドメインレベルのセキュリティでは、SambaサーバはWindowsドメインのメンバとして機能する。Chapter 1 で、各ドメインには通常Windows NT Serverの ドメインコントローラが存在して、パスワード認証を提供していると説明したことを思い出してほしい。このようなコントローラがあると、信頼できるパスワードサーバを備えたワークグループができあがる。ドメインコントローラは、ユーザとパスワードを自身のセキュリティ認証モジュール(SAM)の中に記録し、ユーザが別のマシンの共有に接続しようとしてログオンしてきた時には、個々のユーザを認証する。

> 既に本章で説明したように、Samba にはこれに似た機能として、ユーザレベルのセキュリティがある。ただしこれは UNIX 的なものであり、認証は UNIX のパスワードファイルで行われることを前提にしている。UNIX マシンが NIS や NIS+ ドメインに所属していれば、Samba は通常のUNIXの方式に従い、共有パスワードファイルによってユーザを透過的に認証する。こうすれば、Samba によって Windows から NIS や NIS+ ドメインへのアクセスを提供できる。もちろん NIS のドメインの概念と Windows のドメインの概念とに関係はない。

> ドメインレベルのセキュリティを使えば、NT本来の機構を用いた様々なオプションが使えるようになる。これは様々な利点をもたらす:

> - NTとの親和性がずっと良くなる: 他のWindowsの機能と比べ、ドメインを扱う smb.conf のオプションには「間に合わせ」の部分が少ない。このため、ドメインユーザマネージャのようなNTの管理ツールが利用できるようになり、PC管理者からみると、Sambaサーバが大規模なNTマシンであるかのように扱える。

> - この親和性の向上はプロトコルやコードの整理をもたらし、Samba チームがNTの実装の変化に追随できるようになった。NT Service Pack 4 でプロトコルにあったいくつかの問題点が改善されるが、Sambaの親和性が良くなっているので、これらの変更への追随と対応が容易になる。(nakano 注: この辺なんで原文は現在形なのかな)

> - Sambaサーバとの間に定常的なコネクションを必要としないため、PDCのオーバーヘッドが減る。`security` `=` `server` オプションの時に用いられるプロトコルとは異なり、Samba サーバは認証情報が必要なときだけにリモートプロシジャコール (RPC) を発行する。そのため、定常的なコネクションを維持する必要がない。

> - 最後に、 NTドメインの認証機構は認証の成否だけではなく、 ユーザ属性をフルセットで返却する。この属性には、Unix uid をもっと長く、ネットワーク指向にしたものや、NT グループなどが含まれる。以下のようなものからなる:

>   - ユーザ名

>   - 名前

>   - 説明

>   - セキュリティ識別子(UNIXのuidの概念をドメイン全体に拡張したもの)

>   - NTグループへの所属情報

>   - ログオン可能な時間と、ユーザが直ちにログオフしないといけないかどうかの情報

>   - ユーザが利用可能なワークステーション

>   - アカウントの有効期限

>   - ホームディレクトリ

>   - ログオンスクリプト

>   - プロファイル

>   - アカウントのタイプ

> - Sambaの開発者はSamba 2.0.4から、Sambaサーバ上のドメインユーザを半自動的に作成や削除する方式をドメインレベルのセキュリティで実装した。また、アクセスコントロールリストや、クライアントからファイルアクセス権を変更する機能など、NTライクな各種機能の追加も行なわれている。

> この方式の利点は管理作業の低減にある。同期する必要があるのは、ただ一つの認証データベースだけになる。Sambaサーバ上で必要な管理作業は、ユーザの作業用ディレクトリxを作り、UIDと所属グループの情報とを /etc/passwd のエントリに加えるだけである。

> #### 6.3.4.1 SambaサーバをWindows NTドメインに追加する

> 既にNTドメインがあれば、Sambaサーバは簡単に追加できる。まず最初にSambaサーバを停止する。次に「サーバマネージャ」を利用してSambaサーバをNTドメインに追加する。コンピュータの役割には「Windows NT WorkstationもしくはServer」を選択し、SambaサーバのNetBIOS名を書く。これによりNTサーバ上にマシンアカウントが作成される。

> 次に smbpasswd ツールを利用して、Microsoft形式のマシンパスワードを生成する。このツールについては、次のセクションで詳しく解説する。一例として、ドメイン名がSIMPLEであり、Windows NTのPDCが`beowulf`の場合に、Sambaサーバを追加するために用いるコマンドを示す:

>     smbpasswd -j SIMPLE -r beowulf

> 最後に以下のオプションを smb.confの`[global]` セクションに記述して、Sambaデーモンを再起動する。

>     [global]
>     	security = domain
>     	domain logins = yes
>     	workgroup = SIMPLE
>     	password server = beowulf

> これでSambaはドメインレベルのセキュリティに設定された筈である。`domain` `logins` オプションについてはこの章の後半でもっと詳しく説明する。

6.2 共有に対するアクセス権の制御 |  | 6.4 パスワード

O'Reilly Home | O'Reilly Bookstores | How to Order | O'Reilly Contacts
International | About O'Reilly | Affiliated Companies

© 1999, O'Reilly & Associates, Inc.