06/06/11 03:54:23
>>889
この板にいる人の年齢がわかるレスだな
「熱き心に」を歌いたくなってきた
899:名無しさん＠お腹いっぱい。
06/06/11 22:14:33
Nestle
900:名無しさん＠お腹いっぱい。
06/06/12 09:45:28
LDAPの標準認証って、
userPasswordに {crypt} と {SSHA} が混在してる状況でも、
LDAPサーバ側がユーザの暗号化方式に応じて認証可否を返してくれるもの？
それとも、システム全体で暗号化方式を統一しておく必要があります？
901:名無しさん＠お腹いっぱい。
06/06/12 10:04:54
それはLDAPの仕様じゃなくて、
LDAPサーバの実装仕様によるけれど、
統一しておかないといけないサーバに遭遇したことはないです。
OpenLDAP, iPlanet, Fedora, Netscape, Novell, Active Directoryなど
ただしbasic認証じゃなくて、
自分でuserPassword属性を取得してcrypt()で認証しようとするクライアントが、
結構多いので要注意です。例えばSolarisのpam_ldap。
902:名無しさん＠お腹いっぱい。
06/06/13 09:24:35
>>898
１５０トン。
903:名無しさん＠お腹いっぱい。
06/06/13 10:43:50
>>902
よろしければどんな車に乗っているのかお聞かせ下さい。
＃個人的にはコルトが欲しいです。
904:名無しさん＠お腹いっぱい。
06/06/13 19:06:09
赤いトラクター以外に何か有るとでも言うのだろうか？
905:名無しさん＠お腹いっぱい。
06/06/15 10:23:39
俺はお前だぜ～♪
906:902
06/06/16 16:20:23
はのこほペットにシタクッテっ・・・
それはいい。
OpenLDAP2.4ってな、何時マトモに使えるんだｺﾞﾗ。
907:名無しさん＠お腹いっぱい。
06/06/18 09:30:11
俺はもう OpenLDAP で構築しようとは思わなくなった…
悪いけどプロダクトの質が低いし手間かかりすぎ
908:名無しさん＠お腹いっぱい。
06/06/18 09:58:34
NISのほうが楽そうだな
909:名無しさん＠お腹いっぱい。
06/06/23 00:55:59
UltraPossum使っている人いる？
冗長構成が良さそうだが、いまいち設定の仕方がよくわからない。
VA以外じゃつかってないのか？
910:名無しさん＠お腹いっぱい。
06/06/23 02:58:31
>>907
そうだね。マトモに使うのは楽じゃないかもね。
プロジェクトを進めている学校の質に依存する。
911:名無しさん＠お腹いっぱい。
06/06/23 13:42:43
X.500 なんてもうきっぱり捨てて、BIND 改造して使おうぜ。
912:名無しさん＠お腹いっぱい。
06/06/24 00:23:57
>>911
Kitchen Sink BINDキタコレwww
913:名無しさん＠お腹いっぱい。
06/06/25 19:23:28
それなんてhesiod？
914:名無しさん＠お腹いっぱい。
06/10/24 21:20:45
OpenldapでBIND認証させたユーザに
ある特定のOU配下のみに変更権限を与えることはできますか？
915:名無しさん＠お腹いっぱい。
06/10/30 22:17:12
出来ます。
URLﾘﾝｸ(www.openldap.org)
916:914
06/11/01 00:21:47
>915
ありがとうございます。
試し見てみますね
917:名無しさん＠お腹いっぱい。
06/11/24 03:16:46
openldap サーバ兼クライアント(CentOS 4.4)で、
authconfig をいろいろ書き換えながら ldap ログイン設定をしているのですが、
○ ldap://xxx/ でログインはOK
○ TLS無効時、id [username on ldap] は読める
× TLS有効時、ldaps://xxx/ でログインがだめ
× TLS有効時、id [username on ldap] が読めない
○ TLS有効時、ldapsearch ldaps://xxx/ は読める
な状態に陥っています。
なにから疑えばいいでしょうか。
(/etc/ldap.conf の TLS_REQCERT never は駄目？)
918:名無しさん＠お腹いっぱい。
06/11/24 09:47:13
要するに、
素のLDAP操作(ldapsearch)はOKだが、
pam_ldap, nss_ldapが駄目だということだから、
CentOSのpam_ldap, nss_ldapのパケージに、
専用のLDAP設定ファイルがないか調べてください。
DebianやRHEにはあります。
Libraryが後から読み込むので、
基本設定が、pam_ldap, nss_ldap専用の設定で上書きされます。
それからidコマンドを実行しながら、
etherealでldap, ldapsのパケットを解析してみるのも吉。
919:名無しさん＠お腹いっぱい。
06/11/24 13:39:22
>>917
echo "TLS_REQCERT allow" >> /etc/openldap/ldap.conf
で行くんじゃないかな。/etc/ldap.confとはまた別ものだよ。
920:917
06/11/24 19:46:51
slapd loglevel 256 を tail -f | grep -E "389|636" でみながら試行錯誤したところ、
ssl start_tls だとつながらない
だったので、authconfig 後に
----------
/etc/ldap.conf に URI ldaps と tls_reqcert never 明記
/etc/ldap.conf から ssl start_tls 追放
/etc/openldap/ldap.conf に URI ldaps と tls_reqcert never 明記
----------
にしたところ、
openldap サーバ兼クライアント(CentOS 4.4)
openldap クライアント(CentOS 4.4)
で無事動きました。
start_tls と ldaps は内部的になにがちがうのでしょうか？
921:名無しさん＠お腹いっぱい。
06/11/25 01:03:47
こういう記事があったよ。
URLﾘﾝｸ(www.linux.or.jp)
Note: Start-TLS は、クライアントが要求したときだけ TLS を有効にする
ことができるようにします。この方法だと、単独の LDAP ポートをセキュアな
接続とそうでない接続の両方に使うことが可能です。
922:917
06/11/25 15:09:24
uri 外して ssl on でも動きました。> 921
start_tls だと pam_ldap は 389 を使おうとする
start_tls の pam_ldap 636 は何故か必ず失敗する(tls_reqcert never のせい？)
ので、
ssl on
か
uri ldaps://
で636強制が必要、
という事のようです。
923:名無しさん＠お腹いっぱい。
06/11/25 15:15:57
ldap に限った事じゃないけど、start tls って最初は平文で接続してから ssl に
切り替える物だから、いきなり ssl ポートに接続してもセッションは張れないよ。
924:名無しさん＠お腹いっぱい。
06/11/25 16:09:07
start_tlsはldapポートのまま、tlsネゴシエイトを始めるのね。
要するにアプリケーション層でtlsをコントロールする。
ldapsはセッション層でtls、ldapプロトコルは関与しない。
925:917
06/11/25 16:09:33
start_tls で 389 に接続後、Port 389 のままで SSL になる、という意味でしょうか？
「その場合 SSL が機能していること」はログのどこらへんに注目すればいいでしょうか。
926:917
06/11/25 16:19:13
ちょっと言葉たらずでした。
start_tls 「暗号化されてて安心」の確認は、ログのどこみればいいでしょうか。
これまでやったのはopenladap の
loglevel 256（ポート番号しかわからない感じ）
と
loglevel -1 (大量に出るので何みればいいのかわからない)
の２つです。
927:名無しさん＠お腹いっぱい。
06/11/25 16:28:58
>>925
そうです。
安心したいなら、パケットキャプチャーするのがいいかと。
ログで見たければ、LDAP_DEBUG_STATS。
starttls.cのstarttls_extop()で、
Statslog( LDAP_DEBUG_STATS, "%s STARTTLS\n",
op->o_log_prefix, 0, 0, 0, 0 );
してる。
928:917
06/11/25 17:06:48
loglevel -1 の grep -i tls で
start_tls の id を行うと、
connection_read(12): unable to get TLS client DN error=49 id=【seq】
がかえってきました。
pam_ldap の start_tls は失敗しているようです。
929:名無しさん＠お腹いっぱい。
06/11/25 17:37:46
ここ良く読め。
URLﾘﾝｸ(www.openldap.org)
ここもかな。
URLﾘﾝｸ(www.openldap.org)
930:名無しさん＠お腹いっぱい。
06/12/23 23:13:15
OpenLDAPで構築したサーバと、
SolarisのネイティブLDAPを使ったクライアント。
この組み合わせは無理？
931:名無しさん＠お腹いっぱい。
06/12/24 00:57:17
>>930
LDAPv3であってれば大丈夫じゃない?
経験的に、OpenLDAPのサーバはあまり使いたくないですが。
932:名無しさん＠お腹いっぱい。
06/12/24 10:00:04
>>931
・OpenLDAP を使いたくない理由
・お勧めするDirectory Server
をご教授願いたい
933:名無しさん＠お腹いっぱい。
06/12/24 13:38:26
>>930
Solarisのldapclient manualで設定すれば問題なくLinuxで動いてるOpeｎLDAPサーバのクライアントになれるよ。
4年運用してるけど特に問題ない。
934:名無しさん＠お腹いっぱい。
06/12/24 14:18:55
>>932
931じゃないが、
・パフォーマンス悪い。結構バグがある。
・Netscape直系のヤツ。iPlanet, Sun Java, Red Hatなど。
935:931
06/12/24 22:16:11
>>930
あ、そこに食いつかれるとは思っていませんでした。
使いたくない理由は
・負荷が高いときの動作が怪しいこと
・BDBのハッシュだけがこわれてエントリをことごとく「ない」と応えられて痛い目をみた
お勧め…というか、仕事のシステムで変えられるならこれに変えてみたいというのは
・Sun Java
・Fedora Directory Server
かな。
936:名無しさん＠お腹いっぱい。
06/12/24 22:22:38
同じく931じゃないが。
ヘヴィーな使い方をする場合にOpenLDAPを選択するというのは、
地雷原に突っ込むようなものだ。
軽く使うだけならOpenLDAPでもOK
937:931
06/12/24 22:30:21
あ、FedoraもバックエンドはBDBでした。
ということで、候補からはずしておきます。
(憧れだけで調べてなかったもので…)
938:名無しさん＠お腹いっぱい。
06/12/24 23:08:42
Berkeley DBが悪いんじゃなくて、
OpenLDAPの排他制御に問題があるように感じる。
他にもBerkeley DBを多用するアプリで問題出たことないから。
939:名無しさん＠お腹いっぱい。
06/12/24 23:14:16
OpenLDAPってそんなに問題あるの？
おれの所はSunとつきあいが長いんでSunJava Directory一辺倒だけど。
世の中OpenLDAPがデファクトになりつつあるんで流されようかなと日和って
きたんだが。SambaやWindows連携で良く使われているしさ。
940:名無しさん＠お腹いっぱい。
06/12/24 23:15:26
(931ですが、あまり意味がないので名無しにします)
>>938
MovableTypeとかsubversionとかみてると「やっぱりBDBか?」とおもってしまうんですよぉ。
先入観ですかねぇ。
941:名無しさん＠お腹いっぱい。
06/12/24 23:20:35
openldapを数百万ユーザ規模で動かしてるとこって、かなり
手を入れてるってことなのか。使い方にもよると思うけど、
何ユーザくらいで問題が出たりしてるの？数千くらいだったら
軽いかな？
942:名無しさん＠お腹いっぱい。
06/12/24 23:23:28
そいつらは問題出てるんですか?
spamassassinがperl5の連想配列/libbdb4.4のtieを使ってるんです。
日に万を越えるメールを処理してますが壊れたこと無いですね。
943:名無しさん＠お腹いっぱい。
06/12/24 23:24:59
>>941
VA LinuxがOpenLDAPだけど、
あそこはBackup復旧アプリを付けて出してるよ。
944:名無しさん＠お腹いっぱい。
06/12/25 00:47:13
>>942
直接痛い目にあったわけじゃないですが、結構出てるみたいですよ。
ぐぐってみてください。
私が一番痛い目にあったのはpostfixで宛先の存在を見るようにしてて、
ハッシュが壊れたときにことごとく「ない」と応えてメールを全部叩き落しちゃったこと。
5分くらいで以上に気づいたけど、1000通くらいの被害を出しました。
壊れるタイミングは更新時だけみたい。
ユーザ数は1万弱でメール配送量は1日20000弱。ほとんどがspamですが…。
945:名無しさん＠お腹いっぱい。
06/12/25 01:34:04
942です。
>>944
ごめん。それはOpenLDAPの事例だよね。
>>942ではアンカー付けなかったけど、>>940への問いかけのつもりでした。
OpenLDAPでは、自分もハッシュ壊れを体験してます。
幸い導入前の負荷テストだったので、OpenLDAPは外しました。
DefaultのBerkeley DBしか試してないけど、テストで駄目ならもう信用できないしね。
946:ななし
06/12/25 05:54:20
>>941
数十万エントリで2年運用しているけど
特に問題ないなぁ
947:名無しさん＠お腹いっぱい。
06/12/25 07:22:28
ApacheDSとかプンディレとか使ってる人いらっしゃいますか？
948:名無しさん＠お腹いっぱい。
06/12/25 09:28:28
>>947
プンディレってSun Java Directoryとは別系統なのかなあ？
ApacheDSもちょい興味あり。
949:名無しさん＠お腹いっぱい。
06/12/25 10:15:05
OpenDSはJavaで書いてあるから、
Netscape直系のSun Java Directory Serverとは全く違うだろ。
Sun Java Directory Servderの"Java"には意味がないし。
950:名無しさん＠お腹いっぱい。
06/12/25 11:04:19
Sunは最終的にはOpenDSでJavaDSを置き換える
つもりなのかなぁ？
ApacheDSもJavaだよね？
ちょい試してみようかな。
951:名無しさん＠お腹いっぱい。
06/12/25 11:06:21
てかSunて最近何でも名前にJavaて付けるよな。
952:名無しさん＠お腹いっぱい。
06/12/25 11:26:07
>>950
URLﾘﾝｸ(blogs.sun.com)
URLﾘﾝｸ(opends.dev.java.net)
読む限りでは、置き換えるつもりらしいね。
953:名無しさん＠お腹いっぱい。
06/12/25 11:38:53
ASFは結構仕事早いから、ApacheDSとプンディレ、
どっちがデファクトスタンダードになるかな…。
954:名無しさん＠お腹いっぱい。
06/12/25 11:42:51
>>953
ApacheDSはもう1.0リリースされてるしね。
使ってみた人います？
955:名無しさん＠お腹いっぱい。
06/12/25 11:57:51
OpenDSも社内で一年かけた上でこの夏に公開したらしいぞ。
まだまじめに評価してないけど、(すぐに飛び付くのは時間の無駄なので)
動いてはいるよ。
956:名無しさん＠お腹いっぱい。
06/12/25 12:14:52
>>951
最近はオープンソース化してOpenを付けるのが流行。
プンソラ
プンディレ
プングルオン
…
957:名無しさん＠お腹いっぱい。
06/12/25 13:19:40
でもLDAPクライアントになるソフトウェアに
OpenLDAPライブラリを使って書かれたものが多い
限り、OpenLDAPは捨てられないのか…。
>>956
プンソラとプンディレはよく聞くけど、
プングルオンはさすがに聞いたことないぞwww
958:名無しさん＠お腹いっぱい。
06/12/25 13:25:47
プングルってなに? オープングルメオンパレード?
959:名無しさん＠お腹いっぱい。
06/12/25 13:30:51
>>958
マジレスすると、OpenSSO
…だよな？？？
960:名無しさん＠お腹いっぱい。
06/12/25 13:42:46
>>957
OpenLDAPのライブラリは、
基本部分は、RFC1823 "The LDAP Application Program Interface"
他にはRFCにならなかったdraft、本の少しのOpenLDAP独自拡張。
LDAP関連のRFC draft writerとOpenLDAPのmemberはかなり重なっている。
だからアプリがOpenLDAPのlibldapに依存ってことはほとんどない。
TLS使ったときに、OpenSSLをどういうprofileで使うか、
あたりは潜在的に依存していることがあるだろうけど。
961:名無しさん＠お腹いっぱい。
06/12/25 14:01:16
>>960
OpenDSとかApacheDSとか丸々Javaで書かれた
LDAPシステムだと、libldap自体用意できないから、
OpenLDAPみたいなCやCXXで書かれたLDAPシステムは
捨てられないのかな？程度の意味です。
分かりにくくてごめん。
962:名無しさん＠お腹いっぱい。
06/12/25 14:06:02
>>959
おお、Open Web Single Sign-On、知らなんだ。プングルオンw
963:名無しさん＠お腹いっぱい。
06/12/25 14:08:43
>>961
OpenLDAP のサーバーの、Berkeley DB は悪くなくて更新のとこ、とかいう文脈で、
なぜ OpenLDAP クライアントの C++ のライブラリを捨てなきゃならんという話になるのか?
964:名無しさん＠お腹いっぱい。
06/12/25 14:26:49
>>963
よくわからんが、OpenLDAPの更新の話からは
ぶったぎれてて、単純にプンディレ使うんだったら
クライアントも含めてOpenLDAP捨てて全部
プンディレに移行したいってことじゃね？
965:名無しさん＠お腹いっぱい。
06/12/25 14:38:22
・LDAPはprotocolだけでなくAPIもRFCになっている。
・OpenDSはclientライブラリ作ってない
・OpenLDAPは、DSMLも喋れるJLDAPってのを書いてる
・Sun JDKは、JNDIにLDAP Service Providerを持っている
・mod_ldap, nss_ldapの需要があるからCのライブラリは誰かが維持する。
966:名無しさん＠お腹いっぱい。
06/12/25 14:40:30
>>965
> ・OpenLDAPは、DSMLも喋れるJLDAPってのを書いてる
↓これ。 クライアントライブラリね。
URLﾘﾝｸ(www.openldap.org)
ちなみにOpenDSもDSMLをサポートしてる。(これはサーバ側)
967:名無しさん＠お腹いっぱい。
06/12/25 15:11:33
>>966
こんなの作ってたんだ…知らアッー！！！んかった。
968:名無しさん＠お腹いっぱい。
06/12/26 09:47:44
Contributed by Novell.
以前はOpenLDAPのサイトに載せていながら、
結局 Novell のところでユーザ登録しないと取得できなかったような。
com.novell.* なパッケージもあるし、ほとんどソースが変更されて無いようなので、
「OpenLDAPが書いてる」っていうより、メンテしてるぐらいかな。