トップページ⇒unix
1001コメント287KB

Sun Microsystems 最後の量産

■ このスレッドは過去ログ倉庫に格納されています
0001名無しさん＠お腹いっぱい。2005/05/01(日) 20:00:56
ナイアガラ・・ギャラクシー・・ロック・・・・・・暁・・

【過去スレ】
Sun Microsystem最大の失態
http://pc.2ch.net/test/read.cgi/unix/1006171354/
Sun Microsystems最大の敗退
http://pc.2ch.net/test/read.cgi/unix/1064134161/
Sun Microsystems最大の反省
http://pc.2ch.net/test/read.cgi/unix/1067603469/
Sun Microsystems最大の虚勢
http://pc.2ch.net/test/read.cgi/unix/1073745032/
Sun Microsystems最後の航海
http://pc3.2ch.net/test/read.cgi/unix/1078795800/
Sun Microsystems最後の晩餐
http://pc5.2ch.net/test/read.cgi/unix/1083085439/
Sun Microsystems ラストダンス
http://pc5.2ch.net/test/read.cgi/unix/1086081133/
Sun Microsystems 最後の反撃
http://pc5.2ch.net/test/read.cgi/unix/1088605878/
Sun Microsystems 最後の一葉
http://pc5.2ch.net/test/read.cgi/unix/1094886926/
だまれ小僧！お前にサンが救えるか
http://pc5.2ch.net/test/read.cgi/unix/1103972661/
Sun Microsystems 最後の理不尽
http://pc8.2ch.net/test/read.cgi/unix/1110926614/
0149名無しさん＠お腹いっぱい。2005/05/15(日) 22:26:54
>>148
32bit版きぼんぬ！
0150名無しさん＠お腹いっぱい。2005/05/15(日) 23:15:09
http://pc8.2ch.net/test/read.cgi/unix/1110563961/899
0151名無しさん＠お腹いっぱい。2005/05/15(日) 23:49:27
歴史的な和解劇から1年、MSとSunが再び顔を合わせ、その成果を発表
http://pcweb.mycom.co.jp/news/2005/05/15/100.html
0152名無しさん＠お腹いっぱい。2005/05/15(日) 23:51:26
>>150
すげえ技術みたいだな
0153名無しさん＠お腹いっぱい。2005/05/16(月) 18:22:47
>>150
さらにSunはこの技術を「当社を特許などで訴えない限りにおいて」
自由に利用できるとするライセンスでオープンソースコミュニティに
開放した…
0154名無しさん＠お腹いっぱい。2005/05/16(月) 19:10:40
ttp://www.watch.impress.co.jp/pc/docs/2002/0401/uocchi/msp.htm
これだろ。プレインテキストって。
0155名無しさん＠お腹いっぱい。2005/05/16(月) 23:58:57
>>154
凝りすぎだな>>150の方がおもしろいや
0156名無しさん＠お腹いっぱい。2005/05/17(火) 02:17:57
>>154のは3年前だし
0157名無しさん＠お腹いっぱい。2005/05/17(火) 22:25:47
頑張れ!! SPARC64V
0158名無しさん＠お腹いっぱい。2005/05/17(火) 22:42:38
富士通、2GHzを超えるSPARC64 Vを搭載したSolarisサーバー
http://enterprise.watch.impress.co.jp/cda/hardware/2005/05/17/5266.html

SPARC64VI量産の暁には…
0159名無しさん＠お腹いっぱい。2005/05/17(火) 23:41:46
ベンチマークもやっとなんとかそれらしい数字になった..

ttp://www.spec.org/cpu2000/results/res2005q2/

それに比べると UltraSPARC IIIi 1.6GHz はちと寂しい

ttp://www.spec.org/cpu2000/results/res2005q1/
0160名無しさん＠お腹いっぱい。2005/05/18(水) 03:16:47
>>158のリンク先を読んだ。

> 「PRIMEPOWER 2500」は、同社のストレージシステム
> 「ETERNUS 3000」との組み合わせで、SAPやJavaなど「実際
> の業務に近い業界標準のベンチマークテスト」（山中氏）
> 計6つで世界最高記録を達成したという。

やっと性能面でほぼ追いついたかあ。

> SPARC64 VIは「シングルコアレベルでSPARC64 Vよりさらに
> 20％の性能向上を計画」（サーバシステム事業本部エンター
> プライズサーバ事業部 計画部部長瀬古茂氏）しているとの
> こと。これらの新製品を含めた包括的なラインアップによる
> 「IBMにはない戦略」（山中氏）で、ミドルからハイエンド
> サーバー市場において一人勝ち状態のIBMに追いつき、追い
> 越す構えを見せた。

確かにIBMはミドルからハイエンドまではメインフレーム含め
いろいろあるけど、ローエンドがないんだよね。PC部門は売っ
ぱらっちまったし、そもそもハイエンドとアーキテクチャが
違うし。まあ、だから本家のSun以上にJavaに走ってるわけだ
けど。
0161名無しさん＠お腹いっぱい。2005/05/18(水) 03:18:18
PRIMEPOWER がんがってるね！！
0162名無しさん＠お腹いっぱい。2005/05/18(水) 15:42:00
今日見てたサンのBlog↓の中で、

http://blog.sun.com/roller/main.do

日本の人をみつけました。↓

http://blog.sun.com/roller/page/eota

それだけの話ですが…なんか情報があるかも？
0163名無しさん＠お腹いっぱい。2005/05/18(水) 23:58:15
日本語もありなんだ
ちょっと意外
0164名無しさん＠お腹いっぱい。2005/05/19(木) 21:17:17
ナイアガラまだー？
0165名無しさん＠お腹いっぱい。2005/05/19(木) 21:50:16
あさって出るらしい
0166名無しさん＠お腹いっぱい。2005/05/19(木) 23:01:44
で、出るの？
0167名無しさん＠お腹いっぱい。2005/05/19(木) 23:05:10
お、いよいよか
0168名無しさん＠お腹いっぱい。2005/05/19(木) 23:07:53
嘘を嘘と見抜けないと(ナイアガラを使うことは)難しい。
0169名無しさん＠お腹いっぱい。2005/05/20(金) 00:04:11
>>163
だって日本人もいるじゃんｗ
0170名無しさん＠お腹いっぱい。2005/05/20(金) 00:08:13
ナイアガラ20周年
0171名無しさん＠お腹いっぱい。2005/05/20(金) 00:13:29
Niagara falls
0172名無しさん＠お腹いっぱい。2005/05/20(金) 00:41:58
>>169
うん
でも向こうで働いてる人だし、ブログも英語がデフォかと思って
0173名無しさん＠お腹いっぱい。2005/05/21(土) 01:02:52
ARM互換プロセッサなんかどうでもいいからナイアガラはやくー
0174名無しさん＠お腹いっぱい。2005/05/21(土) 09:39:10
http://www.itmedia.co.jp/enterprise/articles/0505/17/news092.html
IBM、Solaris対抗策でRed Hatと手を組む
0175名無しさん＠お腹いっぱい。2005/05/23(月) 13:20:51
http://japan.zdnet.com/news/devsys/story/0,2000052522,20083699,00.htm
サンがJavaの3次元デスクトップとXMLリッチクライアントをデモ
0176名無しさん＠お腹いっぱい。2005/05/23(月) 17:12:39
今度はCellかよ！大原ぁ
0177名無しさん＠お腹いっぱい。2005/05/24(火) 19:43:06
大原…
0178名無しさん＠お腹いっぱい。2005/05/24(火) 21:09:34
今さらだけど、スレタイﾜﾛﾀ
0179名無しさん＠お腹いっぱい。2005/05/24(火) 22:45:48
Linuxでも使われているNIS(yp)はもともとSolarisなんだけどなあ。
0180名無しさん＠お腹いっぱい。2005/05/25(水) 06:54:15
だからなに？
0181名無しさん＠お腹いっぱい。2005/05/25(水) 23:07:16
IBMにだまされてlinuxを使うと、虎ぶったときに結局IBMの
SEに金を払って来てもらう羽目になる
0182名無しさん＠お腹いっぱい。2005/05/25(水) 23:12:17
SEが来るの？
0183& ◆h9Bn.Lr5Ro 2005/05/25(水) 23:19:36
金を払えば来ます。
0184名無しさん＠お腹いっぱい。2005/05/26(木) 00:28:54
カネ払うって言っても来ないよりマシだな。
0185名無しさん＠お腹いっぱい。2005/05/26(木) 00:33:04
Linux で NIS 使ってるヤツいるか? オレ見たことないぞ。
Web に解説載ってるくらいだからいくらかはいるんだろうけど。
Linux は複数台で協調動作、みたいなことは軒並み苦手という印象がある。
0186名無しさん＠お腹いっぱい。2005/05/26(木) 00:47:51
>>184
来るだけだったりして
0187名無しさん＠お腹いっぱい。2005/05/26(木) 01:28:51
>>185
ふつうに使われてるよ。
でなきゃSolaris→Linuxのリプレースはできない。
0188名無しさん＠お腹いっぱい。2005/05/26(木) 01:46:59
NISはともかくNFSはどうなんだろう
0189名無しさん＠お腹いっぱい。2005/05/26(木) 02:00:47
>>187
えー?? 今どき NIS そんなに使ってるー?
企業じゃもう使ってないんじゃないの? 危ないし。
オレは amd/automount のマップにだけ使ってるけど...
LDAP も使えるんだし。
0190名無しさん＠お腹いっぱい。2005/05/26(木) 02:07:34
奈良先も NIS から LDAP にリプレースしてる。
サーバは主にサン(中身はOpteron)だけど、各種OSのビミョーな非互換性に頭を痛めている模様。
0191名無しさん＠お腹いっぱい。2005/05/26(木) 19:03:38
LinuxでNISもNFSもバリバリ使ってますが、何か?
NISでpasswdとautomoutを管理させとくと、
新しいマシンにLinuxをインストールした場合、
ユーザー登録しなくてもインストール直後に
すぐログインできて、/homeもautomountされるので
すごく便利。2台以上Linux/UNIXマシンがあれば
NIS/NFSは必須でしょう。
0192名無しさん＠お腹いっぱい。2005/05/26(木) 19:40:25
10年以上前のSunOSユーザみたいな自慢だなあ。
0193名無しさん＠お腹いっぱい。2005/05/26(木) 19:41:20
だから、NISじゃなくてもLDAPでできるのよ。
なんでそんな古臭いものを有難がって使ってんだ。何か? とかみっともねえよ。
0194名無しさん＠お腹いっぱい。2005/05/26(木) 20:01:40
そりゃいろいろ考えられるでしょ。たとえば…

使い方にもよるけど、一般論としては毎度TCPコネクションを
張る必要がある分LDAPの方が重いので、NISの方がクライアント
から見て高速だったり、サーバから見て負荷が軽かったりする。

クライアントの中にLDAPに対応してないOS(古いOSとかOpenBSD
とか)が混ざっている。これに対し、NISに対応してないOSはない。

検証してみたら、>>190にあるように、互換性問題が見つかった。

などなど。

セキュリティに関しては、ファイアウォールの内側だったら、
セキュリティポリシー次第でしょ。
packet capture される可能性があるんだったら、LDAP だって
(暗号化した運用をしてない限り) 十分に危険。

条件を勘案せずに、昔のもの→悪い と決めつける方がむしろ
頭悪くない？
0195名無しさん＠お腹いっぱい。2005/05/26(木) 20:35:48
いい機会だから聞いとこ。

>>191
「何か?」って言ったときってどういう反応を期待してるの?
0196名無しさん＠お腹いっぱい。2005/05/26(木) 20:58:23
本人カッコいいと思って使ってるだけだろうから
聞いてもあんまり意味無いと思うよ
0197名無しさん＠お腹いっぱい。2005/05/26(木) 21:06:16
強いて言えば初心者に>>195のような反応をさせること
とか書いてみるテスツ
0198名無しさん＠お腹いっぱい。2005/05/26(木) 22:16:03
>>194
NISだろうとLDAPだろうと、nscd使えばキャッシュが使えるんだから、
「毎度TCPコネクションを張る必要がある」などということはないだろう。

10年前の話じゃあるまいし、ディレクトリサーバってそんなに重いか?
インデックスのキャッシュサイズのチューニングによっては、かなりの
メモリを食わすこともできるが。

また、Solaris 9のリリースノート(もしくは、それに準ずるドキュメント)に、
NISは将来のリリースではサポートされなくなると書いてある。Solaris 10
での扱いは知らないが、早晩「NISに対応してないOS」の一つとして
Solarisを挙げることができるようになるだろう。
0199名無しさん＠お腹いっぱい。2005/05/26(木) 22:22:37
>>198
将来サポートされなくなるのはNIS+の方じゃないのか?
0200名無しさん＠お腹いっぱい。2005/05/26(木) 22:23:12
nscdなんてoffにするのが半常識だろ。
0201名無しさん＠お腹いっぱい。2005/05/26(木) 22:36:12
> また、Solaris 9のリリースノート(もしくは、それに準ずるドキュメント)に、
> NISは将来のリリースではサポートされなくなると書いてある。

これ、NIS+ ができた頃からずっと書いてあるよ。
たぶん NIS の需要が多いため、やめるにやめられないんだと思われ。

そういううちも、相変わらず NIS 使ってます。
NIS クライアントは Solaris, Linux, *BSD といろいろ。
ファイアウォールの内側だし、機能的に十分だし、LDAPへの移行
なんて面倒なことしたくないなあ。
0202名無しさん＠お腹いっぱい。2005/05/26(木) 23:56:57
うーん、NIS って、Linux や NetBSD, FreeBSD に載った時点でもう
収束扱いだったけどな... Sun は NIS+、NIS 開発した連中は NeXT で NetInfo。
NIS じゃユーザー管理したら、パスワードフィールドまる見えでしょ? いくら
「内側」でも、ちょっとセキュリティ感覚を疑うな。利用者全員の素性を把握してる
同好会とかならともかく。
0203名無しさん＠お腹いっぱい。2005/05/27(金) 01:24:09
> NIS じゃユーザー管理したら、パスワードフィールドまる見えでしょ?

これはOS次第。*BSD系で開発されたNISを使っているOSなら、ルート権限
を使って特権ポートをbindした上でアクセスしない限り、パスワード
フィールドをみせないようにすることもできる。

それに LDAP 使ってても、
・デフォルトである "ssl off" で運用している
・ユーザーが管理者権限を得ることが可能
の両方が成り立つなら、arp poisoning 使ってパケット盗聴することに
よって、encrypted passwd を盗み放題なんだよ。
うちの場合ソフト開発が仕事のため、ほとんど全ユーザが クライアント
PC に管理者権限でアクセスできる。従って、ユーザに悪意があるという
脅威を仮定した場合、"ssl on" ないし "ssl starttls" しない限り、
NIS と LDAP に本質的な違いはないんだよねえ。
02042032005/05/27(金) 01:40:45
> arp poisoning 使ってパケット盗聴することに
> よって、encrypted passwd を盗み放題なんだよ。

これ、間違えた。
上記の条件下だと、LDAP を使った場合、encrypted password ではなく、
生パスワードがネットワークを流れる。
確認のため、SSLなしで LDAP 使っているドメインで実際にパケットキャ
プチャしてみたら、生パスワードがもろ見えだった。(arp poisoning し
たんじゃなくて、自分のパスワードで確認したので、悪事を働いたわけ
ではない。)

したがって、こういう条件だと、encrypted password が流れる分、
NIS の方が LDAP よりも、むしろ 安全だと言える。
0205名無しさん＠お腹いっぱい。2005/05/27(金) 02:13:49
そりゃ実装がおかしいんでは? 生パスワードをネットワークに流すなんて、
そんな必要はゼロだよね? なんか違うとこへパスワード入れてるんじゃない?
0206名無しさん＠お腹いっぱい。2005/05/27(金) 03:14:19
> そりゃ実装がおかしいんでは?

試したのは、
ttp://www.atmarkit.co.jp/flinux/rensai/root02/root02a.html
で紹介されている www.padl.com の pam_ldap の実装。
少なくとも Linux で PAM を使う上ではメジャーな実装なんじゃない？
設定も、ほとんどこのページに解説されている通りだと思う。

> 生パスワードをネットワークに流すなんて、そんな必要はゼロだよね?

そうでもない。
ユーザ本人だけしかパスワードアクセスを行なえないようにするには
どうするかを考えてみる。ここで、パスワードデータベースには、
/etc/passwd で使われるものと同じ、DES あるいは MD5 による
encrypted password が格納されているものとする。

ユーザ認証をどのホストで行なうかには、2通りのやり方がある。
1. LDAP クライアント側でユーザ本人であるか検証を行なう
2. LDAP サーバ側でユーザ本人であるか検証を行なう

1. の場合、LDAP サーバから LDAP クライアントへ、encrypted password
を転送しないと、LDAP クライアント側でパスワードが正しいか検証でき
ない。すなわち、ユーザ認証を行なう前に、encrypted password を転送
する必要があるため、「ユーザ本人だけしかパスワードアクセスを行なえ
ないようにする」という目的が、そもそも達成できない。
0207名無しさん＠お腹いっぱい。2005/05/27(金) 03:18:28
2. の場合は、さらに
2.1. LDAP クライアントから LDAP サーバへ生パスワードを送って、
　LDAP サーバ側で MD5/DES 化する。
2.2. LDAP サーバから LDAP クライアントへパスワードの SALT だけ送り、
　LDAP クライアント側で MD5/DES 化して、encrypted password を
　LDAP サーバーへ返す。
の2通りが考えられる。
で、pam_ldap はデフォルトでは 2.1、すなわち生パスワードを送る方法で
動くようだ。これはソースを見れば、LDAP の simple authentication を
使っていることで、確認できる。
ldap.conf で適切な pam_sasl_mech を選べば、後者、すなわち SSL なし
で UNIX 式暗号化パスワードを使った通信も可能だとは思うが、2.2. の
方法を実装している SASL モジュールってあったっけ。CRAM-MD5 も
DIGEST-MD5 も、/etc/passwd とは違うやり方だったと思うが。
0208名無しさん＠お腹いっぱい。2005/05/27(金) 03:34:14
では、仮に 2.2. の方法が実現できたとして、それは安全か？
というと実は安全ではない。
結局のところ 2.2. の方法では、暗号化されたパスワード自体
が、LDAP への認証キーとして使われている。従って、パケット
盗聴してネットワークを流れる encrypted password を盗めば、
それをそのまま使って認証に通ることが可能になる。

だから、NIS は認証手段としてより安全な 1. を使っているわ
けだし、SASL は 2.2. のような危険な認証モジュールを、敢
えて提供してないわけ。

結論としては、ssl を使うように設定してない限り、pam_ldap
を使った認証は、NIS よりもむしろ危険ってことだな。
もちろん ssl を使えば安全だが、当然かなり遅くなる。
0209名無しさん＠お腹いっぱい。2005/05/27(金) 03:48:18
> ssl を使うように設定してない限り、pam_ldap を使った認証は、
> NIS よりもむしろ危険ってことだな。

補足。
ここだけ抜き出して読むと誤解を招くかな。
危険になる原因は、
1. SSL を使ってない
というだけではなく、
2. 本人にしかパスワードアクセスをさせない
3. UNIX passwd 形式の DES ないし MD5 パスワードを使う
といった条件にもあった。
だから、2. の条件のない pam_ldap の実装があれば NIS と同レベル
には安全になるだろう。あるいは www.padl.com の pam_ldap 実装
を使うにしても、3. を諦めて
use_sasl on
pam_sasl_mech GSSAPI
として kerberos で運用するとかすれば大丈夫なんじゃないかな。
良く知らないけど。

2. の条件を課さない pam_ldap 実装ってあるのかな。
0210名無しさん＠お腹いっぱい。2005/05/27(金) 13:04:51
> 2. の条件を課さない pam_ldap 実装ってあるのかな。

Sun の pam_ldap モジュールも、認証機構として simple を
選んだ場合には、ネットワークに平文でパスワードが流れるよっ
て書いてあるね。
ttp://docs.sun.com/db/doc/816-3966/6ma797n02?l=ja&a=view

では SASL 経由で CRAM-MD5 や DIGEST-MD5 を使うのはどうか
というと、こういうチャレンジ・レスポンス型の認証を使う場合、
パスワードデータベースには平文 (ないし平文に変換可能な情報)
で保存する必要があるから、サーバ管理者には、パスワードが
バレバレになるんだよね。
GSSAPI 経由で Kerberos を使う場合も、KDC にはパスワードを
平文で保存することになるし。

サーバ管理者に対しても、ネットワーク盗聴に対しても平文で
パスワードを見せないことを目的にするには、LDAP を使う場合
なら SSL を有効にするしかない。
SSL を使う気がないなら、NIS を使った方がまだマシ。

LDAP → 新しいから安全
NIS → 古いから危険
なんて単純な考えは実は大間違いってことだな。
まあ、技術の中身を知らない人が、単に新しいだけでそれを優れ
てるって思い込むことって、他にも色々多いよね。
0211名無しさん＠お腹いっぱい。2005/05/27(金) 13:44:33
>>210
木を見て森を見ずというか、ボロボロなこと言っとるな。
0212名無しさん＠お腹いっぱい。2005/05/27(金) 13:47:50
>>211
例えばどこら辺が？
おいらもパケットダンプしてみたが、確かに平文で流れてたよ。
というわけで、SSL を使うように変更中… orz
0213名無しさん＠お腹いっぱい。2005/05/27(金) 14:23:44
211は、既に顧客のシステムをNISからLDAPに移行させちゃってる
(当然SSLなし)ので、自分の間違いを認めることができないんじゃ
ないの？ 自分の誤りを認めると、お客さんのところに謝りに行っ
て設定変更する必要が生じる。だから、210が間違ってると無理
矢理信じこもうとしてると考えると辻褄があう希ガス。
つまり、ボロボロなのは210じゃなくて211の(ry
0214名無しさん＠お腹いっぱい。2005/05/27(金) 14:24:15
NISでencrypted passwordが平文で
絶対流れないようにするには
どうすればいいですか
0215名無しさん＠お腹いっぱい。2005/05/27(金) 14:24:35
NISでencrypted passwordが平文で
絶対流れないようにするには
どうすればいいですか
0216名無しさん＠お腹いっぱい。2005/05/27(金) 14:28:31
Solaris に限れば、secure RPC 使えばできるんじゃない？
0217名無しさん＠お腹いっぱい。2005/05/27(金) 14:45:30
NIS over secure RPC って、サポートされてたっけ？
NIS+ の方はデフォルトで secure RPC 上で動いてたと
思うけど。

で、NIS の場合は、IPsec の上で動かせば大丈夫だと
思う。この方法なら、Solaris に限らず動く筈。
まあ secure RPC も IPsec も、要は暗号化してるわけで、
暗号化する負荷が気にならないんだったら、LDAP で SSL
でもいいじゃんと思うけどね。

ファイアウォールの内側なので暗号化するほどの機密性は
要らないし、むしろ暗号化のための負荷が気になるっていう
場合は、SSL なしで LDAP 使うくらいなら NIS の方がマシっ
ていうのは 210 の通り。
0218名無しさん＠お腹いっぱい。2005/05/27(金) 14:59:18
SSL は認証のところで公開鍵暗号を使うから重いイメージがある。
共有鍵設定で IPsec を使った方が軽いんじゃないかなあ。
いや、実際に計ってみたわけじゃないですが。
0219名無しさん＠お腹いっぱい。2005/05/27(金) 17:00:36
>>209
> pam_sasl_mech GSSAPI
> として kerberos で運用するとかすれば大丈夫なんじゃないかな。

なんでわざわざpam-ldapからkerberos使わなきゃならんのだよ…
pam-krb5があるのにさ。

SASLでS/Key、SSLなしつーのなら分かるけども。
>>211に同意で、もうちょっと整理してから出直した方がいい。
0220名無しさん＠お腹いっぱい。2005/05/27(金) 17:01:39
>>217
> NIS over secure RPC って、サポートされてたっけ？

SolarisはOK。NFSもね。
0221名無しさん＠お腹いっぱい。2005/05/27(金) 17:09:38
> なんでわざわざpam-ldapからkerberos使わなきゃならんのだよ…
> pam-krb5があるのにさ。

kerberos realm と、そのマシンにアカウントのあるユーザが
一致している場合は pam-krb5 でいいけど、ユーザを realm
のサブセットにしたい場合には pam-ldap を使ってユーザを
制限して、ただし認証は KDC に頼るって運用がしたいことも
あるんじゃない？

> SASLでS/Key、SSLなしつーのなら分かるけども。

そう？ s/key って、ファイアウォールの内側で使うような
ものじゃないと思うけど。で、ファイアウォールの外側で
使う場合、SSL なしだと LDAP の TCP コネクションが乗っと
られる可能性があるから危険じゃない？
0222名無しさん＠お腹いっぱい。2005/05/27(金) 17:11:46
>>221
詭弁の一種、極論ですね。
0223名無しさん＠お腹いっぱい。2005/05/27(金) 17:16:03
そうかなあ。確認だけど、219は、ファイアウォールの
内側で s/key を使うって言ってるの？ それとも外側？

今回の件はNISで始まっているから、基本的にはファイア
ウォールの内側の話だと思うだけど。

だとすると、s/key は論外だと思う。
だからといって、SSL なし の LDAP simple authentication
で生パスワードが流れるのは、いくら社内だからと言っても
避けたいというのは割と分かる話じゃない？
0224名無しさん＠お腹いっぱい。2005/05/27(金) 17:21:32
>>223
> だからといって、SSL なし の LDAP simple authentication
> で生パスワードが流れるのは、

こんなの極端なのを持ってきて、NISの方がいいって言う論法もどうかしている。

特にSolarisのLDAPによる認証とNISの認証は、
・LDAPはdefaultはclient側でcryptして認証する方式
・流れるのはcryptedなpassword
・secure RPC, SSLなどの暗号化のoptionがある
ということでほとんど変わりがない。

NIS+ならまだアクセスで個人認証ができるからNISよりは優位性がある。

0225名無しさん＠お腹いっぱい。2005/05/27(金) 17:25:36
> 特にSolarisのLDAPによる認証とNISの認証は、
> ・LDAPはdefaultはclient側でcryptして認証する方式
> ・流れるのはcryptedなpassword

ははあ、なるほど。Solaris 附属の LDAP の場合、
>>206 の言う 1.、>>209 の言う 2. の機能があるわけ
ですか。だとすると NIS と同じですね。

Linux が混ざったりして、PADL の実装を使う場合にまずいと。
02262252005/05/27(金) 17:28:15
> >>209 の言う 2. の機能があるわけ

s/の言う 2. の機能/の言う 2. の条件を課さない実装/
0227名無しさん＠お腹いっぱい。2005/05/27(金) 17:56:26
勝手にまとめると、サーバ側に encrypted password を保存する
タイプの認証手段を選ぶ場合、

SSL なり secure RPC なり IPsec なりで暗号化する場合:
・LDAP と NIS+ は OK。
・NIS だと encrypted password を誰でも見れるので、お勧めできない。
　ただし *BSD 系の NIS 実装に統一できるなら、この問題を回避できる。
・SSL が使えるのは LDAP。secure RPC が使えるのは NIS+ と NIS。
　IPsec は全てで使える。

暗号化しない場合:
・Solaris の pam_ldap で適切に設定するなら OK。
・PADL の pam_ldap の場合、平文パスワードが流れるのでお勧めできない。
・NIS+ だと、普通そういう選択肢はない。(デフォルトで secure RPC)
・NIS もまあ OK。

ってところかな。
0228名無しさん＠お腹いっぱい。2005/05/27(金) 18:17:26
「*BSD 系の NIS」ってやつだけど、

- 適当なマシンを（無許可で勝手に）接続
- root 権限で ypcat
- おウチへ持ち帰って総当たり

は避けれないよね? NIS で指摘されてた欠点ってこういうことだったと
思うけど.. LDAP でも同じなの? ホント??

ところで、LDAP サーバー側でユーザー認証とか出てたけど、それ一体何?
なんでそんな必要があるの??? どういう利点があるの? クライアントには
OK/NG が戻るんだよね? それ盲目的に信じて動くわけ?
0229名無しさん＠お腹いっぱい。2005/05/27(金) 18:34:23
> 「*BSD 系の NIS」ってやつだけど、
略
> は避けれないよね?

暗号化（IPsec など）を使うのであれば避けられます。

暗号化しない場合、LDAP でも、
- 適当なマシンを（無許可で勝手に）接続
- root 権限で ARP poisoning して packet capture
- Solaris の pam_ldap の場合、userPassword属性が読める。
　PADL の pam_ldap の場合、生パスワードがそのまま見える。
という危険があります。

従って、暗号化しない場合、Solaris 版だと LDAP も NIS と同程度の
危険性があり、PADL 版の場合、NIS よりむしろ危ないと思われます。

> LDAP サーバー側でユーザー認証とか出てたけど、それ一体何?
> なんでそんな必要があるの??? どういう利点があるの? クライアントには
> OK/NG が戻るんだよね? それ盲目的に信じて動くわけ?

そういうことになります。利点はLDAPスレの
http://pc8.2ch.net/test/read.cgi/unix/1012650811/611
のPADLの項に書いてある通り。
0230名無しさん＠お腹いっぱい。2005/05/27(金) 18:54:01
>>229
わかってないヤカン。
0231名無しさん＠お腹いっぱい。2005/05/27(金) 19:02:50
どこら辺が？
0232名無しさん＠お腹いっぱい。2005/05/27(金) 19:10:01
このスレでLDAPを安全だと思ってる人って、
ldapsearch -x -b ほげほげ '(objectclass=*)'
のようなコマンドで、ypcatと同じことがLDAPでもできるって
ことを知らないような気がする。

PADL版で運用している場合は、こうやってもuserPassword属性
は読めないんだけど、Solaris版なら読めるのでNISと同じ。
じゃあPADL版は安全かというと生パスワードが流れるわけで。
0233名無しさん＠お腹いっぱい。2005/05/27(金) 19:16:15
NISの盗聴の危険性を聞かれてるのに
IPSecで答えたつもりなのって何かおかしいような
0234名無しさん＠お腹いっぱい。2005/05/27(金) 19:25:11
>>229が書いているのは、NISで盗聴できる場合は、LDAPでも盗聴
できるし、特にPADL版のLDAPの場合、NISで盗聴した場合以上に、
盗聴の被害が大きいってことでしょ。

LDAPでも暗号化すれば盗聴を防げるけど、NISでもIPsecで暗号化
すればやはり盗聴できないからやはり同じ。(IPsec の鍵を知らな
い限り、勝手に接続してypcatしても失敗するだけ)

LDAP で CRAM-MD5 や DIGEST-MD5 を使えば、暗号化しなくても
盗聴を防げる。でも、>>227 ではサーバ側に encrypted password
を保存する (cleartext password をサーバ管理者に見せない)
という条件がついてるから、現在のスレの話の範疇から外れてる。

結局分かってないのは>>230だったってことでは？
0235名無しさん＠お腹いっぱい。2005/05/27(金) 19:34:35
ここ見てるとUNIXはユーザ認証関係でWindowsより劣ってるように見えるぞ
0236名無しさん＠お腹いっぱい。2005/05/27(金) 19:38:28
そういえばファイル共有に関してもWindowsの方が手軽のような気がする
WindowsServerなら、時間や日付、曜日によってアクセスできなくさせたりできるし
グループを入れ子にしてアクセス権設定できる
0237名無しさん＠お腹いっぱい。2005/05/27(金) 19:39:58
Windows の認証方式は encrypted password をネットワークに
流すが、実はその encrypted password 自体が認証キーとして
使われるというものなので、ほとんど cleartext 認証と変わら
んよ。駄目駄目。
だからといって、認証手段を PAM みたいに簡単に変更できるわ
けでもないし。
0238名無しさん＠お腹いっぱい。2005/05/27(金) 19:52:43
>>237
WindowsはActiveDirectory使う場合はKerberos認証なんじゃないの？
0239名無しさん＠お腹いっぱい。2005/05/27(金) 20:02:24
Active Directory の場合はそうね。
でもその場合は UNIX で LDAP + Kerberos するのと同じでしょ。
Active Directory の実体は LDAP なんだし。
0240名無しさん＠お腹いっぱい。2005/05/27(金) 20:09:43
Windows2000やWindowsXPの場合はアカウントの一元管理する場合、
ActiveDirectory使うのが普通なんだが
0241名無しさん＠お腹いっぱい。2005/05/27(金) 20:13:24
で、その Windows と同じことは UNIX でも LDAP と
Kerberos でできると。
UNIX の場合 nsswitch と pam で、他のディレクトリ
サービス (NIS とか NIS+ とか、Active Directory
とか、あるいは独自開発したものとか) を使うことも
できるが、Windows だと選択不能だと。
0242名無しさん＠お腹いっぱい。2005/05/27(金) 20:21:58
選択不能だから、詳しくない人間に変にいじられなくてすむってのはあるな
UNIXの場合、rootは神だけどWindowsの場合、Administratorは神とよべるほと権限ないし
0243名無しさん＠お腹いっぱい。2005/05/28(土) 00:21:37
神はゲイシ
0244名無しさん＠お腹いっぱい。2005/05/28(土) 00:23:31
MS-Windows は認証周り難しいから、ユルユルか典型的設定になってるのが
ほとんど。Unix くらい単純にしといて、sudo で細かくやるっての
悪くないと思うけど。まあ後付けモノだけどね。
OS の認証周りの仕掛けの不具合は Unix くらい単純でもいろいろ出てくるから、
MS-Windows くらい大掛かりだとデバッグはかなり大変なはず。
0245名無しさん＠お腹いっぱい。2005/05/28(土) 00:36:08
結局 N1 Grid使えば人称とかもブレイクスルーなんｄあろ？　ぐちゃぐちゃ文句いうなよね！
0246名無しさん＠お腹いっぱい。2005/05/28(土) 00:53:08
NIS 用に IPsec で 1 網作る、ってのは斬新だと思った。
LDAP で各種 OS 安定して相互運用できるようになるまでそれも
いいかも。物理的なセグメントも越えられるし。
0247名無しさん＠お腹いっぱい。2005/05/28(土) 01:05:55
やたら伸びてると思ったら、既にSunは関係ねーｗ
0248名無しさん＠お腹いっぱい。2005/05/28(土) 04:29:51
ZFS実装の暁には！
■ このスレッドは過去ログ倉庫に格納されています