[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[plamo:18280] Re: PAM



From: "KAMOSAWA, Masao" <jcd00743@nifty.ne.jp>
Message-Id: <3E940CFB.2449@nifty.ne.jp>

> > 「PAM *も*」というのはちょっと違うんじゃないかな? 私の認識だと,PAM =
> > Pluggable Authentification Module だから,PAM という枠組の中で,使う認
> > 証用モジュールを切り換えることで,UNIX passwd やら LDAP やら,バイオメ
> > トリックス認証やらを使えるようになるんではないかと思っています.
> 
> PAM を使わずに login なりなんなりを LDAP やらなにやらに対応することはで
> きるというか、Sun が PAM を開発する以前にはそうやって開発が進められてい
> たわけです。ですから、PAM を使わず login を直接 LDAP に対応させるような
> アプローチと、PAM を使って認証する形式は併存させることができます。

確かにそうですが、UNIXで伝統的なpasswd認証以外にいろいろサポートしよう
と思ったら、認証したい全てのサーバの設定を当たってまわったり、あるいは
パッチ当てたり再コンパイルしたりってのは、もはや美しい解だとは思えませ
ん。

PAMのミソは、雑多な認証メソッドをPAMという1つの層で仮想化することです
が、そういうアイデア自体は、もはやありふれたものですし、これで見通しが
悪くなるようこともないような気がします。

# もちろん、非PAMな手法でLDAPやらにアプローチするのも正しい解の1つだと
# は思いますが。

> だから PAM を入れるなら一気に移行した方がいいですよと言いたい・・・ので
> すが、反面、PAM + LDAP だとか PAM + SQL認証だとか、PAM + Samba +
> Windows2000 のディレクトリサービス、なんて構成は Plamo のシンプルさにそ
> ぐわないような感じも抱いているので躊躇していたわけです。

たしかに、伝統的なpasswd認証から踏み出すと、ちょっとシンプルとは言いが
たくなりますが、デフォルト設定で使っている限りはシンプルな世界を維持で
きるわけです。一方、ユーザのニーズとして、それ以外の高度な認証をしたい
と思ったら、各サーバを各自対応させるよりも、PAMを使った方が、作る側も
いじる側も楽なわけです。

> まったく、UNIX passwd だけの単純さも実に捨て難いですよね。LAN のユーザー
> 管理が二重になったとしても、それが苦になるような巨大ネットワークを管理し
> ているわけではないし、トラブルが起きた際にどちらの方が解決が簡単か、わか
> ったものではないと思ってもいます。

巨大でなくても、Sambaを上げてsmbpasswdを保守しようと思った瞬間に、LDAP
が欲しくなったりすることもなきにしもあらず。

> とりあえず PAM + shadow のみで作って提供するのがいいのかなあ。
> 動作検証も楽だし。

でいいと思いますよ。実際、PAMを使ってる他のディストリビューションも、
せいぜいMD5なパスワードを使ってるくらいですし。

# それでつい最近までPAMのメリットが見えなかったやつ :-)
_______________________________
田原 俊一   jado@flowernet.gr.jp, shunichi_tahara@zenrin.co.jp
                                  http://flowernet.gr.jp/jado/
FingerPrint:  16 9E 70 3B 05 86 5D 08  B8 4C 47 3A E7 E9 8E D9
 ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄

Follow-Ups
[plamo:18283] Re: PAM, KATOH Yasufumi
References
[plamo:18275] Re: LDAP, KAMOSAWA, Masao
[plamo:18276] PAM(Re: Re: LDAP), KOJIMA Mitsuhiro
[plamo:18279] Re: PAM(Re: Re: LDAP), KAMOSAWA, Masao

[検索ページ] [メール一覧]
Plamo ML 公開システム