Chapter 28. PAM ベースの分散型認証
Prev | Part III. 詳細な設定方法 | Next

## Chapter 28. PAM ベースの分散型認証

### John H. Terpstra

Samba Team

`<jht@samba.org>`

### Stephen Langasek

`<vorlon@netexpress.net>`

May 31, 2003

この章は、何らかの PAM が利用できる UNIX/Linux システムに対して Winbindベースの認証を導入する際の助けになるだろう。Winbind を使うと、いずれかのWindows NT ドメイン、Windows 200x の Active Directory ベースのドメイン、そして Samba ベースのドメイン環境において、ユーザレベルのアプリケーションアクセス認証を利用できるようになる。また、あなたの Samba 環境の設定に対する適切な PAM ベースのローカルホストアクセス制御にも役立つ。

PAM 経由の Winbind の設定方法を知ることに加え、さらに一般的な PAM 管理の可能性と、特に `pam_smbpass.so` のようなツールを導入して便利に使う方法も学ぶことができるだろう。

### Note

Winbind を使うのは、PAM 構成を単独で行うよりも敷居が高い。Winbind に関するより詳細な情報についてはWinbind: ドメインアカウントを使うを参照されたい。

## その機能と利点

現在、多くの UNIX システム（例：Oracle(Sun)Solaris）や xxxxBSDファミリーおよびLinux では、着脱可能な認証モジュール(PAM)機能を使って全ての認証、承認処理、リソースの制御サービスを提供している。PAM の導入以前は、システムパスワードデータベース(`/etc/passwd`)以外のものを使おうとするなら、セキュリティサービスを提供するすべてのプログラムそれぞれに対して代替手段を準備する必要がある。つまり、`login`, `passwd`, `chown` といったものの代替手段を別途用意しなければならないということである。

PAM を使うと、これらのセキュリティプログラムを、これらが依存する認証／承認インフラから切り離すことができる。PAM を構成するには、`/etc/pam.conf` という１つのファイルを適切に変更する(Solaris)か、または`/etc/pam.d`配下にある個別の制御ファイルを編集する。

PAM が有効になっている UNIX/Linux システムでは、動的なロードができる適切なライブラリモジュールが利用できるようになっていれば、システムでさまざまな認証バックエンドを使うように構成するのは簡単である。それらのバックエンドはシステムでローカルに閉じていてもよいし、リモートサーバ上で集約されていてもよい。

PAM サポートモジュールで使えるもの：

`/etc/passwd`

  これらの PAM モジュールは標準の UNIX ユーザデータベースを利用する。最も有名なものは、`pam_unix.so`, `pam_unix2.so`, `pam_pwdb.so`,`pam_userdb.so`と呼ばれるものである。

Kerberos

  `pam_krb5.so` モジュールを使うと、ケルベロス準拠のあらゆるサーバを使える。このツールは MIT Kerberos, Heimdal Kerberos, そしておそらく（もし有効であれば）Microsoft Active Directory にアクセスするのにも使える。

LDAP

  `pam_ldap.so` モジュールを使うと、LDAP v2 もしくは v3準拠のあらゆるバックエンドサーバを使える。よく使われる LDAP バックエンドサーバには OpenLDAP v2.0 and v2.1, Sun ONE iDentity server, Novell eDirectory server, Microsoft Active Directory がある。

NetWare Bindery

  `pam_ncp_auth.so` モジュールを使うと、バインダリ(Bindery)が有効な NetWare コアプロトコルベースのサーバによる認証を利用できるようになる。

SMB Password

  `pam_smbpass.so` と呼ばれるモジュールを使うと、Samba の`smb.conf` ファイルで設定された passdb バックエンドのユーザ認証を利用できるようになる。

SMB Server

  `pam_smb_auth.so` モジュールは、オリジナルの MS Windowsネットワーク認証のためのツールである。Winbind モジュールがリリースされている現在、このモジュールはすでに多少古臭くなってしまっている。

Winbind

  `pam_winbind.so` モジュールは、Samba は MS Windows のドメインコントローラーからの認証情報を取得できるようにするものである。これにより、PAM が有効なアプリケーションに対して認証されたユーザへのアクセス権を与えるのが簡単になる。

RADIUS

  PAM RADIUS (Remote Access Dial-In User Service) と呼ばれる認証モジュールがある。ほとんどのケースでは、管理者がこのツールのソースコードを持ってきて自分自身でインストールを行う必要がある。RADIUS プロトコルは多くのルータやターミナルサーバで使われているプロトコルである。

上記のうち、`pam_smbpasswd.so` と `pam_winbind.so`モジュールは、Samba 自身が提供するものである。

いったんこれらのモジュールを設定してしまえば、広範囲にまたがるネットワーク帯域や PAM を利用した効率的な認証サービスを提供するような分散 Samba ドメインコントローラの利用においても、高い柔軟性を得ることができる。つまり、単一のユーザアカウントデータベースを使って、中央集中的な管理や保守の行き届いた分散認証を実現できるのである。

## 技術的な議論

システム管理者が自分のシステム上のアプリケーションにアクセス権を付与する際、PAM はかなり柔軟に設定できるように設計されている。PAM によって制御されるシステムセキュリティのためのローカル設定には、単一ファイル `/etc/pam.conf` と `/etc/pam.d/`ディレクトリーの２つがある。

### PAM 設定のための文法

この章では、これらのファイルで記述するエントリに関する正しい文法、および一般的なオプションについて解説する。設定ファイルにおける PAM 特有のトークンでは、大文字小文字の区別を行わない。ただし、モジュールのパスについては大文字小文字を区別する。なぜなら、これらはファイルの名前を示すものであり、大文字小文字を区別するような一般的なファイルシステムの性質に影響を受けるからである。与えられたモジュールに渡すための引数が大文字小文字を区別するかどうかは、それぞれのモジュールで規定されている。

後述の設定行に加え、システム管理者の便宜のために２つの特殊文字がある：“#” から行末まではコメントとみなされる。またモジュールを指定する行については “\” で改行をエスケープすることで、次の行にまたがることができる。

PAM の認証モジュール（ダイナミックリンクされたライブラリファイル）が既定値の位置にある場合は、そのパスを明示する必要はない。Linux の場合、既定値の位置は `/lib/security` となる。モジュールが既定値位置以外にある場合は

    auth  required  /other_path/pam_strange_module.so

のようにパスを明示しなければならない。

#### `/etc/pam.d` にあるエントリーの構造

このセクションの残りの部分は、Linux-PAM プロジェクトのドキュメントからの引用である。PAM に関する詳細はthe Official Linux-PAM home pageを参照のこと。

`/etc/pam.conf` ファイル中の一般的な設定行は、以下の書式で記述する：

    サービス名  モジュールタイプ  制御フラグ  モジュールパス  引数

これら各トークンの意味について解説する。Linux-PAM を構成するための2番目のやり方（最近はむしろこちらの方が多いようだが）は、`/etc/pam.d/` ディレクトリーの中身を介するという方法である。それぞれのトークンの意味するところを解説した後、この方法について述べることにする。

サービス名

  このエントリに関連付けられるサービスの名前。`ftpd`, `rlogind`, `su` のように、サービス名はアプリケーションにつけられた伝統的な名前であることが多い。

  既定値の認証メカニズムを定義するために予約されている、特別な名前もある。これは `OTHER` と呼ばれるが、大文字小文字は固定されていない。名前付きサービスに特化したモジュールがある場合、`OTHER`エントリーは無視される事に注意。

モジュールタイプ

  （現時点では）以下の通り4つのタイプのモジュールがある。

  - `auth:` このモジュールタイプは、ユーザを認証するにあたって２つの側面がある。まず、アプリケーションに対してパスワード問い合わせの指示を行うか、または別の手段を使って、操作しているユーザが誰なのかを特定する。次に、このモジュールはその資格認定から承認という性質を通して(`/etc/groups` ファイルとは独立した形で)グループの会員資格やその他の特権に関する許可を与えることができる。

  - `account:` このモジュールは、認証をベースとしないアカウント管理を行う。よくある利用法としては、利用時間帯、現時点で利用可能なシステムリソース（最大ユーザ数）、またはユーザがログインした場所などをベースとした、サービスへのアクセスの制限や許可が挙げられる。たとえば “root” ログインの許可は、コンソールからのみに制限されているかもしれない。

  - `session:` このモジュールは、主に対象のユーザがサービスを割り当てられる前後に行われるべきことに関連付けられる。たとえばそのユーザに関する何らかのデータ交換をする際のオープン/クローズ情報のログを取ったり、ディレクトリをマウントすることなどが挙げられる。

  - `password:` この最後のモジュールタイプは、そのユーザに関連する認証トークンを更新するために必要なものである。典型的には、“チャレンジ/レスポンス” 認証を行う`(auth)` モジュールタイプがある。

制御フラグ

  制御フラグは、関連するモジュールの成功／失敗に対して PAMライブラリがどう対応するのかを指示するのに使われる。PAM モジュール群はスタック化(同じタイプのモジュール群を次々に重ねること)できるので、制御フラグがそれぞれのモジュールの相対的な重要度を決定する。アプリケーションは `/etc/pam.conf` ファイルにあるモジュールについて、個々の成功や失敗に影響されない。その代わり、Linux-PAM ライブラリからの成功や失敗の応答のサマリを受け取る。これらのモジュールは、`/etc/pam.conf` に記述されている順に実行される。つまり前の方にあるエントリは後ろの方のものより先に実行される。Linux-PAM v0.60 の場合、制御フラグは２つの文法のうちのいずれかで定義できる。

  制御フラグについてのシンプルな(かつ従来の)文法では、特定のモジュールの成功や失敗について、それらを通知するための重大度を単一のキーワードで指定する。キーワードには `required`, `requisite`, `sufficient`, `optional` の4種類ある。

  Linux-PAM ライブラリでは以下の方式でこれらのキーワードを 解釈する。

  - `required:`このモジュールタイプ機能が成功するためにはこのモジュールが成功することが必須である。ただしこのモジュールが失敗した場合でも、(同じモジュールタイプを持つ)残りのすべてのモジュールの実行が完了するまでは、失敗したことはユーザには通知されない。

  - `requisite:` required と似ているが、このモジュールが失敗を返したとき制御が直接アプリケーションに戻されるところが異なる。その戻り値は、失敗したモジュールのうち最初に required もしくは requisite 指定されていたものに関連付けられる。安全でない媒体を通してユーザがパスワードを入力するような可能性がある場合、このフラグはその状況を排除するために使える。そのような可能性が残っていると、システム上の有効なアカウントの情報を攻撃者に知らせてしまうようなことにつながりかねない。このような可能性があると、共用ホスト環境で慎重に扱うべきパスワードを公開してしまうようなゆゆしき環境において、一方的に不利になるだろう。

  - `sufficient:` このモジュールが成功すると、Linux-PAM ライブラリがこのモジュールタイプについてその目的を達成したものとするのに`sufficient`(十分である)とみなされる。これまでに要求されたモジュールのうち失敗したものがない場合、このタイプに関して“スタックされた”モジュールは、これ以上起動されない(この場合、この後に続くモジュールは起動されない)。ただし、このモジュールが失敗しても、このモジュールタイプレベルで成功したアプリケーションについては致命的エラーとはみなされない。

  - `optional:` この制御フラグは、その名前が示しているように、そのモジュールの成功/失敗が、そのユーザアプリケーションがサービスを提供できるかどうかを決めるものではないことを示す。一般に、そのモジュールスタック全体が成功か失敗かを決定する際、Linux-PAM はこのようなモジュールを考慮しない。しかしながら、それ以前もしくはそれ以降のどのモジュールも明確に成功か失敗かを示さない場合、このモジュールがアプリケーションへの応答の性質を決めることがある。後者のひとつの例として、他のモジュールが PAM_IGNORE のようなものを返した場合が挙げられる。

  ユーザを認証する方法について、その文法が複雑に(新しく)なればなるほど、管理者はより詳しく記述し、より細かく制御できるようになるものである。この制御フラグの書式は、以下のように`値=アクション` トークンの並びが大括弧で区切られたものである:

      [値1=アクション1 値2=アクション2 ...]

  ここで、`値1` は以下の戻り値のいずれかである:

      success; open_err; symbol_err; service_err; system_err; buf_err;perm_denied; auth_err; cred_insufficient; authinfo_unavail;user_unknown; maxtries; new_authtok_reqd; acct_expired; session_err;cred_unavail; cred_expired; cred_err; no_module_data; conv_err;authtok_err; authtok_recover_err; authtok_lock_busy;authtok_disable_aging; try_again; ignore; abort; authtok_expired;module_unknown; bad_item; と default.

  最後の`default`は、明示的に定義されない戻り値に対する動作を規定するのに使える。

  `アクション1` には正の整数かまたは以下のトークンのいずれかを指定する:`ignore`; `ok`; `done`;`bad`; `die`; `reset`.正の整数 J がアクションとして指定された場合、現在のモジュールタイプについて続く J 個のモジュールをスキップする。この方法により、管理者は異なった実行パスを持つ多くのスタックされたモジュールを、適度に洗練された方法で組み合わせることができる。個々のモジュールの反応によって、どのパスにあるものが適用されるかが決定される。

  - `ignore:` モジュールスタックに対して使われると、そのモジュールの戻り値は、アプリケーションが受け取るリターンコードには影響しない。

  - `bad:` このアクションが指定されると、戻り値はモジュールの失敗を表しているとみなされる。このモジュールがスタックの中で最初に失敗すると、その戻り値はスタック全体の値として使われる。

  - `die:` bad と同じだが、さらにモジュールスタックが終了して即時に PAM がアプリケーションに結果を返す。

  - `ok:` この戻り値をモジュールスタック全体の戻り値として直接返すべきだと管理者が考えていることを PAM に教える。つまり、このスタックの直前の状態が戻り値 PAM_SUCCESS を返すことになっていた場合は、モジュールの戻り値がこの値を上書きする。もしスタックの直前の状態が特定のモジュールの失敗を表す何らかの値を保持している場合は、この `ok`値はその値を上書きしない。

  - `done:` `ok` と同じだが、モジュールスタックを終了させて PAM の制御を即時にアプリケーションに戻すという副作用があるところが異なる。

  - `reset:` モジュールスタックの状態を保持するメモリをクリアし、次のスタックモジュールから実行を再開する。

  `required`; `requisite`;`sufficient`; `optional`はそれぞれ [...] という構文をもつという意味では同等の、以下の表現を備えている：

  - `required` は`[success=ok new_authtok_reqd=ok ignore=ignore default=bad]`と同等。

  - `requisite` は`[success=ok new_authtok_reqd=ok ignore=ignore default=die]`と同等。

  - `sufficient` は`[success=done new_authtok_reqd=done default=ignore]`と同等。

  - `optional` は`[success=ok new_authtok_reqd=ok default=ignore]`と同等である。

  この新しい書式が持つパワーの感触をつかむために、これで何ができるのかを体験してみるとよいだろう。Linux-PAM-0.63 ではクライアント・プラグイン・エージェントの概念が導入された。これにより、PAM ではクライアント・サーバ・アプリケーションに対して、トランスポート・プロトコルの継承を利用したマシン間の認証を可能にしている。`[ ... value=action ... ]` という制御用構文により、アプリケーションがそれに準拠するクライアントに対してバイナリ・プロンプトのサポートを構成できるようになっている。ただしレガシーアプリケーションの場合は柔軟に代替認証モードにフェイルオーバーできる。

module-path

  動的ローダブルオブジェクトファイルのパス名 - 差し替え可能なモジュールそのもの。モジュールパスの最初の文字が“/” の場合、それは絶対パスであるとみなされる。そうでない場合、与えられたモジュールパスは既定値のモジュールパスである `/lib/security` の後ろに付加される(ただし前述の注意事項を参照のこと)。

  引数は、起動時にモジュールに渡されるトークンのリストであり、典型的なLinux のシェルコマンドへの引数と同様である。一般的に、有効な引数はオプションであり、与えられたモジュール固有のものであることが多い。無効な引数はモジュールによって無視される。しかしながら、無効な引数に出会った場合、そのモジュールは syslog(3) に対してエラーメッセージを出力しなければならない。共通的なオプションについては次の節を参照して欲しい。

  引数の中に空白を含める場合は引数全体を大括弧 [] で括るようにする。次に例を示す:

      squid auth required pam_mysql.so user=passwd_query passwd=mada \db=eminence [query=select user_name from internet_service where \user_name=“%u” and password=PASSWORD(“%p”) and service=“web_proxy”]

  この書式を使う場合は文字列の中に “[” 文字を含んでもよい。また文字列の中に “]” 文字を含める場合は、引数の解析が正しく行えるように “\[” を使うべきである。すなわち以下のようになる。

      [..[..\]..]    -->   ..[..]..

  設定ファイルの中でひとつでも書式が正しくない行があれば、(エラーが起こって)認証処理は失敗すると思った方がよい。対応するエラーはsyslog(3) への呼び出しを通してシステムのログファイルに書き込まれる。

### システム設定の例

以下は設定ファイル `/etc/pam.d/login`の例である。この例ではすべてのオプションがコメント状態をはずされて(=有効になって)おり、おそらくこのままでは使い物にならないだろう。というのは、ログインプロセスが成功するまでに多くの条件が積み重なっているからである。`pam_pwdb.so` の呼び出しを除き、原則的にはすべての条件をコメントアウトして無効にすることができる。

#### PAM: オリジナルのログイン設定

    #%PAM-1.0# The PAM configuration file for the “login” service#auth         required    pam_securetty.soauth         required    pam_nologin.so# auth       required    pam_dialup.so# auth       optional    pam_mail.soauth         required    pam_pwdb.so shadow md5# account    requisite   pam_time.soaccount      required    pam_pwdb.sosession      required    pam_pwdb.so# session    optional    pam_lastlog.so# password   required    pam_cracklib.so retry=3password     required    pam_pwdb.so shadow md5

#### PAM: `pam_smbpass` を使ったログイン

PAM では交換式モジュールが利用できる。サンプルシステムでは以下のものが利用可能:

`$``/bin/ls /lib/security`

    pam_access.so    pam_ftp.so          pam_limits.so     pam_ncp_auth.so  pam_rhosts_auth.so  pam_stress.so     pam_cracklib.so  pam_group.so        pam_listfile.so   pam_nologin.so   pam_rootok.so       pam_tally.so      pam_deny.so      pam_issue.so        pam_mail.so       pam_permit.so    pam_securetty.so    pam_time.so       pam_dialup.so    pam_lastlog.so      pam_mkhomedir.so  pam_pwdb.so      pam_shells.so       pam_unix.so       pam_env.so       pam_ldap.so         pam_motd.so       pam_radius.so    pam_smbpass.so      pam_unix_acct.so  pam_wheel.so     pam_unix_auth.so    pam_unix_passwd.sopam_userdb.so    pam_warn.so         pam_unix_session.so

以下のログインプログラムの例では、システムパスワードデータベース(`/etc/passwd`,`/etc/shadow`, `/etc/group`) を使う `pam_pwdb.so` を`pam_smbpass.so` で置き換えている。後者では Microsoft MD4 暗号化パスワードハッシュを含む Samba のデータベースを使う。このデータベースは使用している UNIX/Linux システムの実装により`/usr/local/samba/private/smbpasswd`, `/etc/samba/smbpasswd`,`/etc/samba.d/smbpasswd`のいずれかに格納される。`pam_smbpass.so` モジュールは Samba 2.2.1 以降で提供される。このモジュールをコンパイルしたい場合は、Samba の `configure` スクリプト実行時に `--with-pam_smbpass` オプションを指定する。`pam_smbpass` モジュールに関する詳細については Samba ソースの配布物の`source/pam_smbpass` ディレクトリにあるドキュメントを参照して欲しい。

    #%PAM-1.0# The PAM configuration file for the “login” service#auth        required    pam_smbpass.so nodelayaccount     required    pam_smbpass.so nodelaysession     required    pam_smbpass.so nodelaypassword    required    pam_smbpass.so nodelay

以下に、ある Linux システムにおける PAM の設定ファイルを示す。既定値の設定では `pam_pwdb.so` を使う。

    #%PAM-1.0# The PAM configuration file for the “samba” service#auth       required     pam_pwdb.so nullok nodelay shadow auditaccount    required     pam_pwdb.so audit nodelaysession    required     pam_pwdb.so nodelaypassword   required     pam_pwdb.so shadow md5

以下の例では、基本的な Samba 認証であっても`smbpasswd` データベースを使うようになっている。このような設定を行った場合、`passwd` プログラムに対しても影響を及ぼす。つまり、`smbpasswd` のパスワードを `passwd` コマンドで変更できるようになる:

    #%PAM-1.0# The PAM configuration file for the “samba” service#auth       required     pam_smbpass.so nodelayaccount    required     pam_pwdb.so audit nodelaysession    required     pam_pwdb.so nodelaypassword   required     pam_smbpass.so nodelay smbconf=/etc/samba.d/smb.conf

### Note

PAM では階層的な(スタックされた)認証の仕組みを提供している。たとえば、ある PAM モジュールが受け取った情報を、PAM スタックの次のモジュールに渡すことができる。PAM に関する特定の機能の詳細については、お使いのシステムに特化したドキュメントを参照して欲しい。さらにいくつかの Lunux の実装では、すべての認証を中心となる単一のファイルで設定できる `pam_stack.so` と呼ばれるモジュールが提供されている。`pam_stack.so` 方式は管理者の手間を軽減してくれるので、熱心なファンもいる。もっとも、環境によってもいろんな問題があるわけであり、前述のどの方式を取るにしてもそれぞれのトレードオフがある。より有益な情報を探すために、PAM のドキュメントをあたってみるのもよいだろう。

### `smb.conf` の PAM 設定

obey pam restrictions と呼ばれる `smb.conf` のオプションがある。このオプションに関する SWAT のヘルプを以下に示す：

> Samba が PAM サポート (`--with-pam`) 付きでコンパイルされている場合、Samba が PAM の account および session 管理ディレクティブに従うかどうかをこのパラメータで 制御できる。PAM を使うが認証は平文のみで、かつどの account/session 管理も無視するというのが既定値の動作である。encrypt passwords = yesの場合、Samba は常に認証については PAM を無視する。その理由は、SMB パスワード暗号を使う場合に必要なチャレンジ／レスポンス方式の認証メカニズムを PAM モジュールが サポートしていないからである。

> 既定値:obey pam restrictions = no

### `winbindd.so`を使った遠隔 CIFS 認証

どんな OS であっても、その OS 自身がアクセス可能なユーザ証明情報が(どこからか)提供されていることを前提としている。UNIX ではユーザ識別子(UID)だけでなくグループ識別子(GID)も必要となる。これらはいずれも単純な整数値であり、`/etc/passwd` といったパスワードバックエンドより取得する。

Windows NT サーバでは、ユーザとグループは相対ID(RID)に割り当てられている。これらはユーザやグループが作られる際、ドメイン毎に一意となる。Windows NT のユーザやグループを UNIX のユーザやグループに変換するためには、RID と UNIX のユーザ/グループの ID をマッピングする必要がある。これが winbind が行う仕事のひとつである。

winbind のユーザとグループはサーバから解決要求が出され、ユーザとグループの ID が指定された範囲内で割り当てられる。クライアントがユーザとグループを列挙するコマンドを実行すると、すぐに既存の全ユーザとグループがマッピングされ、割り当て処理が先着順に行われる。割り当てられた UNIX ID は Samba の lock ディレクトリ配下のデータベースファイルに保持されて記憶される。

これにより、目先が利く管理者なら、`pam_smbpass.so` や`winbindd` と、`ldap` のような分散型の passdb backend との組み合わせにより、(Linux のような)PAM を意識したプログラムやアプリケーションからも使うことのできる、中央集権型で管理された分散型のユーザ/パスワードデータベースが使えるようになるということが理解できるだろう。このお膳立てにより、広範囲のネットワーク認証のトラフィックが削減できるという限りにおいては、マイクロソフトのActive Directory Service(ADS)に比較して、特に強力な優位性を持てる。

### Warning

UNIX の ID データベースに対応する RID はユーザとグループのマッピングが格納されているファイルにのみ存在し、`winbindd` によって格納される。このファイルが削除されていたり壊れていたりする場合、`winbindd` はどのユーザやグループが Windows NTのユーザやグループの RID と対応するのかを決定できなくなる。

### `pam_smbpass.so` を使ったパスワードの同期

`pam_smbpass` は PAM モジュールのひとつであり、システム上で `smbpasswd` (Sambaのパスワード)データベースと UNIX のパスワードファイルとの同期を取るために使われる。PAM は Solaris, HPUX, Linux などの UNIX オペレーティングシステム上でサポートされている API であり、認証メカニズムに対する標準的なインターフェースを提供する。

このモジュールはローカルにある `smbpasswd` ユーザデータベースを使って認証する。リモートの SMB サーバで認証したり、システム上の SUID root されたバイナリの存在を調べたいという向きには、`pam_winbind` の方を使うことをお勧めする。

このモジュールで認識されるオプションについては、次のテーブルを参照して欲しい。

Table 28.1. `pam_smbpass`で認識されるオプション

debug | より多くのデバッグ情報を出力する
audit | debugと似ているが、認識できないユーザ名も表示する
use_first_pass | ユーザにパスワード入力を求めない。パスワードは PAM_ 項目から持ってくる
try_first_pass | 直前の PAM モジュールからパスワードの取得を試みる。取得できなければユーザからの入力を求める。
use_authtok | try_first_pass に似ているが、(パスワードモジュールだけをスタックさせるための)新しい PAM_AUTHTOK が事前にセットされていなければ『失敗する』
not_set_pass | このモジュールで使われたパスワードを他のモジュールに流用させない
nodelay | 認証の失敗までに最大1秒の遅延を挟まない
nullok | パスワードなしを認める
nonull | パスワードなしを認めない。これは Samba の設定に優先する。
migrate | “auth” コンテキストでのみ意味を持つ。成功した認証で使われたパスワードを使って smbpasswd ファイルを更新する。
smbconf=`ファイル名` | `smb.conf` ファイルへの別のパスを指定する

Linux の `/etc/pam.d/` 形式のファイル構造で`pam_smbpass.so` を使うときの例を以下に示す。このツールを別のプラットフォームに実装したいと思っている方は、適当に読み替えてみてほしい。

#### パスワードの同期設定

以下の PAM 設定例では、`/etc/passwd (/etc/shadow)` が変更されたときに、pam_smbpass を利用して`private/smbpasswd`が連動して変更されるようにしている。これはパスワードの有効期限が切れたときに(`ssh`のような)アプリケーションがパスワードを変更するような場合に便利である。

    #%PAM-1.0# password-sync#auth       requisite    pam_nologin.soauth       required     pam_unix.soaccount    required     pam_unix.sopassword   requisite    pam_cracklib.so retry=3password   requisite    pam_unix.so shadow md5 use_authtok try_first_passpassword   required     pam_smbpass.so nullok use_authtok try_first_passsession    required     pam_unix.so

#### パスワード移行のための設定

以下は `pam_smbpass` を使って平文からSamba 用の暗号化パスワードに移行するための PAM 設定である。他のメソッドと違い、この方法なら一度も Samba の共有に接続したことがなくても使える:パスワードを移行すれば、ユーザが`ftp` で接続したり、`ssh`でログインしてメールを取り出したりする場合などにも使える。

    #%PAM-1.0# password-migration#auth       requisite   pam_nologin.so# pam_smbpass is called IF pam_unix succeeds.auth       requisite   pam_unix.soauth       optional    pam_smbpass.so migrateaccount    required    pam_unix.sopassword   requisite   pam_cracklib.so retry=3password   requisite   pam_unix.so shadow md5 use_authtok try_first_passpassword   optional    pam_smbpass.so nullok use_authtok try_first_passsession    required    pam_unix.so

#### 従来のパスワード設定

以下の例は、従来の `smbpasswd` 利用時のためのPAM 設定である。`private/smbpasswd` 全体が投入され、SMB パスワードが存在しなかったり UNIX のパスワードと合致しない場合はエラーと見なされる。

    #%PAM-1.0# password-mature#auth       requisite    pam_nologin.soauth       required     pam_unix.soaccount    required     pam_unix.sopassword   requisite    pam_cracklib.so retry=3password   requisite    pam_unix.so shadow md5 use_authtok try_first_passpassword   required     pam_smbpass.so use_authtok use_first_passsession    required     pam_unix.so

#### Kerberosパスワード統合設定

以下の PAM 設定例は、`pam_krb5` といっしょに使われる `pam_smbpass` を示している。これは Samba PDC 上で、かつそれがkerberos realmのメンバである場合に有用である。

    #%PAM-1.0# kdc-pdc#auth       requisite   pam_nologin.soauth       requisite   pam_krb5.soauth       optional    pam_smbpass.so migrateaccount    required    pam_krb5.sopassword   requisite   pam_cracklib.so retry=3password   optional    pam_smbpass.so nullok use_authtok try_first_passpassword   required    pam_krb5.so use_authtok try_first_passsession    required    pam_krb5.so

## よくあるエラー

PAM は割と扱いづらく、設定エラーを引き起こしやすい。以下にSamba のメーリングリストで見かけたいくつかのケースを紹介する。

### pam_winbind の問題

あるユーザからPAM の設定で以下の問題が起こったとの報告があった:

    auth required /lib/security/pam_securetty.soauth sufficient /lib/security/pam_winbind.soauth sufficient /lib/security/pam_unix.so use_first_pass nullokauth required /lib/security/pam_stack.so service=system-authauth required /lib/security/pam_nologin.soaccount required /lib/security/pam_stack.so service=system-authaccount required /lib/security/pam_winbind.sopassword required /lib/security/pam_stack.so service=system-auth

[ctrl][alt][F1]で新しくコンソールを開くと、私の ID “pitie” ではログインできない。ユーザ “scienceu\pitie” でやってみたが、それでもだめだった。

この問題は`pam_stack.so service=system-auth`がある時に発生する。このファイルに入っている多くの設定には、すでに実行中ものが二重に入っていることがよくある。`auth` と `account`から `pam_stack` の行をコメントアウトしたらどうなるかやってみてくれ。それで動くなら、`/etc/pam.d/system-auth` ファイルを見て、その中で本当に必要な行だけを `/etc/pam.d/login`ファイルにコピーすればいい。別のやり方として、もしすべてのサービスで winbind を動かしてもいいなら、`/etc/pam.d/system-auth` に winbind 固有の設定を追加してもいい。

### Winbind がユーザとグループを解決してくれない

“僕の `smb.conf` は正しく設定されている。idmap uid = 12000 とidmap gid = 3000-3500を指定しているし `winbind` も動いている。以下のコマンドはちゃんと動いている。 ”

    root# wbinfo -uMIDEARTH\maryoMIDEARTH\jackbMIDEARTH\ameds...MIDEARTH\rootroot# wbinfo -gMIDEARTH\Domain UsersMIDEARTH\Domain AdminsMIDEARTH\Domain Guests...MIDEARTH\Accountsroot# getent passwdroot:x:0:0:root:/root:/bin/bashbin:x:1:1:bin:/bin:/bin/bash...maryo:x:15000:15003:Mary Orville:/home/MIDEARTH/maryo:/bin/false

“しかし、このコマンドが失敗する: ”

    root# chown maryo a_filechown: 'maryo': invalid user

“一体どうなってんの？何か間違ってる？”

名前キャッシュデーモンである `nscd` が動いてるんじゃないかな？そいつを終わらせて、起動しないようにしてくれ。それでうまくいくと思うよ。

Prev | Up | Next
Chapter 27. デスクトッププロファイルの管理 | Home | Chapter 29. Microsoft Windows ネットワークへのSambaの統合