目次
この章は、何らかの 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.so
auth required pam_nologin.so
# auth required pam_dialup.so
# auth optional pam_mail.so
auth required pam_pwdb.so shadow md5
# account requisite pam_time.so
account required pam_pwdb.so
session required pam_pwdb.so
# session optional pam_lastlog.so
# password required pam_cracklib.so retry=3
password 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.so pam_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 nodelay
account required pam_smbpass.so nodelay
session required pam_smbpass.so nodelay
password 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 audit
account required pam_pwdb.so audit nodelay
session required pam_pwdb.so nodelay
password 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 nodelay
account required pam_pwdb.so audit nodelay
session required pam_pwdb.so nodelay
password 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
の方を使うことをお勧めする。
このモジュールで認識されるオプションについては、 次のテーブルを参照して欲しい。
表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.so auth required pam_unix.so account required pam_unix.so password requisite pam_cracklib.so retry=3 password requisite pam_unix.so shadow md5 use_authtok try_first_pass password required pam_smbpass.so nullok use_authtok try_first_pass session 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.so auth optional pam_smbpass.so migrate account required pam_unix.so password requisite pam_cracklib.so retry=3 password requisite pam_unix.so shadow md5 use_authtok try_first_pass password optional pam_smbpass.so nullok use_authtok try_first_pass session required pam_unix.so
以下の例は、従来の smbpasswd
利用時のための
PAM 設定である。private/smbpasswd
全体が
投入され、SMB パスワードが存在しなかったり UNIX のパスワードと
合致しない場合はエラーと見なされる。
#%PAM-1.0 # password-mature # auth requisite pam_nologin.so auth required pam_unix.so account required pam_unix.so password requisite pam_cracklib.so retry=3 password requisite pam_unix.so shadow md5 use_authtok try_first_pass password required pam_smbpass.so use_authtok use_first_pass session required pam_unix.so
以下の PAM 設定例は、pam_krb5
といっしょに
使われる pam_smbpass
を示している。
これは Samba PDC 上で、かつそれがkerberos realmのメンバーで
ある場合に有用である。
#%PAM-1.0 # kdc-pdc # auth requisite pam_nologin.so auth requisite pam_krb5.so auth optional pam_smbpass.so migrate account required pam_krb5.so password requisite pam_cracklib.so retry=3 password optional pam_smbpass.so nullok use_authtok try_first_pass password required pam_krb5.so use_authtok try_first_pass session required pam_krb5.so
PAM は割と扱いづらく、設定エラーを引き起こしやすい。以下に Samba のメーリングリストで見かけたいくつかのケースを紹介する。
あるユーザーからPAM の設定で以下の問題が起こった との報告があった:
auth required /lib/security/pam_securetty.so auth sufficient /lib/security/pam_winbind.so auth sufficient /lib/security/pam_unix.so use_first_pass nullok auth required /lib/security/pam_stack.so service=system-auth auth required /lib/security/pam_nologin.so account required /lib/security/pam_stack.so service=system-auth account required /lib/security/pam_winbind.so password 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\maryo MIDEARTH\jackb MIDEARTH\ameds ... MIDEARTH\rootroot#
wbinfo -g
MIDEARTH\Domain Users MIDEARTH\Domain Admins MIDEARTH\Domain Guests ... MIDEARTH\Accountsroot#
getent passwd
root:x:0:0:root:/root:/bin/bash bin: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
が動いてる
んじゃないかな?そいつを終わらせて、起動しないようにしてくれ。
それでうまくいくと思うよ。