Table of Contents
この章は、何らかの PAM が利用できる UNIX/Linux システムに対して Winbindベースの認証を導入する際の助けになるだろう。Winbind を使うと、いずれかのWindows NT ドメイン、Windows 200x の Active Directory ベースのドメイン、そして Samba ベースのドメイン環境において、ユーザレベルのアプリケーションアクセス認証を利用できるようになる。また、あなたの Samba 環境の設定に対する適切な PAM ベースのローカルホストアクセス制御にも役立つ。
PAM 経由の Winbind の設定方法を知ることに加え、さらに一般的な PAM 管理の可能性と、特に pam_smbpass.so
のようなツールを導入して便利に使う方法も学ぶことができるだろう。
Winbind を使うのは、PAM 構成を単独で行うよりも敷居が高い。Winbind に関するより詳細な情報についてはWinbind: ドメインアカウントを使うを参照されたい。
現在、多くの UNIX システム(例:Oracle(Sun)Solaris)や xxxxBSDファミリーおよびLinux では、着脱可能な認証モジュール(PAM)機能を使って全ての認証、承認処理、リソースの制御サービスを提供している。PAM の導入以前は、システムパスワードデータベース(/etc/passwd
)以外のものを使おうとするなら、セキュリティサービスを提供するすべてのプログラムそれぞれに対して代替手段を準備する必要がある。つまり、login
, passwd
, chown
といったものの代替手段を別途用意しなければならないということである。
PAM を使うと、これらのセキュリティプログラムを、これらが依存する認証/承認インフラから切り離すことができる。PAM を構成するには、/etc/pam.conf
という1つのファイルを適切に変更する(Solaris)か、または/etc/pam.d
配下にある個別の制御ファイルを編集する。
PAM が有効になっている UNIX/Linux システムでは、動的なロードができる適切なライブラリモジュールが利用できるようになっていれば、システムでさまざまな認証バックエンドを使うように構成するのは簡単である。それらのバックエンドはシステムでローカルに閉じていてもよいし、リモートサーバ上で集約されていてもよい。
PAM サポートモジュールで使えるもの:
/etc/passwd
これらの PAM モジュールは標準の UNIX ユーザデータベースを利用する。最も有名なものは、pam_unix.so
, pam_unix2.so
, pam_pwdb.so
,pam_userdb.so
と呼ばれるものである。
pam_krb5.so
モジュールを使うと、ケルベロス準拠のあらゆるサーバを使える。このツールは MIT Kerberos, Heimdal Kerberos, そしておそらく(もし有効であれば)Microsoft Active Directory にアクセスするのにも使える。
pam_ldap.so
モジュールを使うと、LDAP v2 もしくは v3準拠のあらゆるバックエンドサーバを使える。よく使われる LDAP バックエンドサーバには OpenLDAP v2.0 and v2.1, Sun ONE iDentity server, Novell eDirectory server, Microsoft Active Directory がある。
pam_ncp_auth.so
モジュールを使うと、バインダリ(Bindery)が有効な NetWare コアプロトコルベースのサーバによる認証を利用できるようになる。
pam_smbpass.so
と呼ばれるモジュールを使うと、Samba のsmb.conf
ファイルで設定された passdb バックエンドのユーザ認証を利用できるようになる。
pam_smb_auth.so
モジュールは、オリジナルの MS Windowsネットワーク認証のためのツールである。Winbind モジュールがリリースされている現在、このモジュールはすでに多少古臭くなってしまっている。
pam_winbind.so
モジュールは、Samba は MS Windows のドメインコントローラーからの認証情報を取得できるようにするものである。これにより、PAM が有効なアプリケーションに対して認証されたユーザへのアクセス権を与えるのが簡単になる。
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/
ディレクトリーの2つがある。
この章では、これらのファイルで記述するエントリに関する正しい文法、および一般的なオプションについて解説する。設定ファイルにおける PAM 特有のトークンでは、大文字小文字の区別を行わない。ただし、モジュールのパスについては大文字小文字を区別する。なぜなら、これらはファイルの名前を示すものであり、大文字小文字を区別するような一般的なファイルシステムの性質に影響を受けるからである。与えられたモジュールに渡すための引数が大文字小文字を区別するかどうかは、それぞれのモジュールで規定されている。
後述の設定行に加え、システム管理者の便宜のために2つの特殊文字がある:“#” から行末まではコメントとみなされる。またモジュールを指定する行については “\” で改行をエスケープすることで、次の行にまたがることができる。
PAM の認証モジュール(ダイナミックリンクされたライブラリファイル)が既定値の位置にある場合は、そのパスを明示する必要はない。Linux の場合、既定値の位置は /lib/security
となる。モジュールが既定値位置以外にある場合は
auth required /other_path/pam_strange_module.so
のようにパスを明示しなければならない。
このセクションの残りの部分は、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:
このモジュールタイプは、ユーザを認証するにあたって2つの側面がある。まず、アプリケーションに対してパスワード問い合わせの指示を行うか、または別の手段を使って、操作しているユーザが誰なのかを特定する。次に、このモジュールはその資格認定から承認という性質を通して(/etc/groups
ファイルとは独立した形で)グループの会員資格やその他の特権に関する許可を与えることができる。
account:
このモジュールは、認証をベースとしないアカウント管理を行う。よくある利用法としては、利用時間帯、現時点で利用可能なシステムリソース(最大ユーザ数)、またはユーザがログインした場所などをベースとした、サービスへのアクセスの制限や許可が挙げられる。たとえば “root” ログインの許可は、コンソールからのみに制限されているかもしれない。
session:
このモジュールは、主に対象のユーザがサービスを割り当てられる前後に行われるべきことに関連付けられる。たとえばそのユーザに関する何らかのデータ交換をする際のオープン/クローズ情報のログを取ったり、ディレクトリをマウントすることなどが挙げられる。
password:
この最後のモジュールタイプは、そのユーザに関連する認証トークンを更新するために必要なものである。典型的には、“チャレンジ/レスポンス” 認証を行う(auth)
モジュールタイプがある。
制御フラグは、関連するモジュールの成功/失敗に対して PAMライブラリがどう対応するのかを指示するのに使われる。PAM モジュール群はスタック化(同じタイプのモジュール群を次々に重ねること)できるので、制御フラグがそれぞれのモジュールの相対的な重要度を決定する。アプリケーションは /etc/pam.conf
ファイルにあるモジュールについて、個々の成功や失敗に影響されない。その代わり、Linux-PAM ライブラリからの成功や失敗の応答のサマリを受け取る。これらのモジュールは、/etc/pam.conf
に記述されている順に実行される。つまり前の方にあるエントリは後ろの方のものより先に実行される。Linux-PAM v0.60 の場合、制御フラグは2つの文法のうちのいずれかで定義できる。
制御フラグについてのシンプルな(かつ従来の)文法では、特定のモジュールの成功や失敗について、それらを通知するための重大度を単一のキーワードで指定する。キーワードには 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 ... ]
という制御用構文により、アプリケーションがそれに準拠するクライアントに対してバイナリ・プロンプトのサポートを構成できるようになっている。ただしレガシーアプリケーションの場合は柔軟に代替認証モードにフェイルオーバーできる。
動的ローダブルオブジェクトファイルのパス名 - 差し替え可能なモジュールそのもの。モジュールパスの最初の文字が“/” の場合、それは絶対パスであるとみなされる。そうでない場合、与えられたモジュールパスは既定値のモジュールパスである /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-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 では交換式モジュールが利用できる。サンプルシステムでは以下のものが利用可能:
$
/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
PAM では階層的な(スタックされた)認証の仕組みを提供している。たとえば、ある PAM モジュールが受け取った情報を、PAM スタックの次のモジュールに渡すことができる。PAM に関する特定の機能の詳細については、お使いのシステムに特化したドキュメントを参照して欲しい。さらにいくつかの Lunux の実装では、すべての認証を中心となる単一のファイルで設定できる pam_stack.so
と呼ばれるモジュールが提供されている。pam_stack.so
方式は管理者の手間を軽減してくれるので、熱心なファンもいる。もっとも、環境によってもいろんな問題があるわけであり、前述のどの方式を取るにしてもそれぞれのトレードオフがある。より有益な情報を探すために、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 モジュールが サポートしていないからである。
どんな 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)に比較して、特に強力な優位性を持てる。
UNIX の ID データベースに対応する RID はユーザとグループのマッピングが格納されているファイルにのみ存在し、winbindd
によって格納される。このファイルが削除されていたり壊れていたりする場合、winbindd
はどのユーザやグループが Windows NTのユーザやグループの RID と対応するのかを決定できなくなる。
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
以下の 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 の設定で以下の問題が起こったとの報告があった:
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 固有の設定を追加してもいい。
“僕の smb.conf
は正しく設定されている。idmap uid = 12000 とidmap gid = 3000-3500を指定しているし winbind
も動いている。以下のコマンドはちゃんと動いている。 ”
root#
wbinfo -u
MIDEARTH\maryoMIDEARTH\jackbMIDEARTH\ameds...MIDEARTH\rootroot#
wbinfo -g
MIDEARTH\Domain UsersMIDEARTH\Domain AdminsMIDEARTH\Domain Guests...MIDEARTH\Accountsroot#
getent passwd
root: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_file
chown: 'maryo': invalid user
“一体どうなってんの?何か間違ってる?”
名前キャッシュデーモンである nscd
が動いてるんじゃないかな?そいつを終わらせて、起動しないようにしてくれ。それでうまくいくと思うよ。