- - PR -
ActiveDirectry上に対し、ユーザ検索を行っても属性が取得できない
| 投稿者 | 投稿内容 |
|---|---|
|
投稿日時: 2007-10-24 11:36
ActiveDirectry上に以下のユーザが存在します。
・ユーザ名 ："34044" ・パスワード："H0YYRT" このユーザは、以下の位置にエントリーされています。 ・BaseDNが「DC=AAA,DC＝BBB」の下の「CN=USER」という層の下に 「CN＝test」として登録されています。 ActiveDirectryに対し、以下の情報で接続をしました。 接続するときは、AnonymousBindではなく、以下のとおり UserInfo情報も付与した形で接続しております。 ・接続URL ：HTTP://ADサーバのIPアドレス：389 ・ドメイン ：AAA.BBB ・BaseDN ：DC=AAA,DC＝BBB ・フィルタ ：CN=test ・接続ユーザ：CN＝test＠AAA.BBB その結果、ユーザ認証自体は"true"が返ってくるのですが、ユーザ"test"の エントリー位置(CN=USER,DC=AAA,DC＝BBB)が返ってこず、以下のエラーが 返ってきます。 ⇒エラーはここから javax.naming.AuthenticationException:[LDAP:error code 49-80090308:ldapErr:DSID-0c090334,comment: AcceptSecurityContext error,data 525,vece ⇒エラーはここまで LdapBrowserでは、上記の接続情報で接続をして、問題なくエントリー位置が返ってきます。 何が原因なのかが分かりません。いろいろ調べてみると、AD側のバインド認証というもので でひっかかっているのではないかとの情報を得ており、これはAD側のセキュリティ 設定環境のことだろうとの推測はしているのですが、AD側のどのようなセキュリティ情報に ひっかかっているのかがよくつかめておりません。 上記の接続プログラムは以下の環境で動かしており、LdapBrowserもこの端末にいれて ADへの接続テストを行いました。 OS ：WindowsXP Webサーバ ：tomcat5.5.1.7 プログラム ：jsp LdapBrowserですと、問題なくエントリー位置が返ってくるのに、jspプログラムですと、 なぜ、上記のエラーとなり、エントリー位置が返ってこないのでしょうか。 経験豊富な皆様方、同じような経験をされた方や、回避策をご存知の方、AD側のこの阻害 原因となっているセキュリティ設定にお詳しい方、どなたかご教示頂けましたら幸甚でございます。 何卒宜しく御願いいたします。 |
|
投稿日時: 2007-10-24 14:54
説明に誤りがございましたので以下に訂正いたします。
このユーザは、以下の位置にエントリーされています。 ・BaseDNが「DC=AAA,DC＝BBB」の下の「CN=USER」という層の下に 「CN＝test」として登録されています。 ↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓ このユーザは、以下の位置にエントリーされています。 ・BaseDNが「DC=AAA,DC＝BBB」の下の「CN=USER」という層の下に 「CN＝34044」として登録されています。 |
|
投稿日時: 2007-10-24 18:19
チャブーンです。
エラーメッセージから、バインド自体に問題が起こっているのでしょう。 ところで、 > BaseDNが「DC=AAA,DC＝BBB」の下の「CN=USER」という層の下に「CN＝34044」として登録されています。 ということですが、Active Directory のデフォルトコンテナの Users にオブジェクトを納めているなら、CN=34044,CN=Users,DC=AAA,DC=BBB という DN になります。DN の指定は本当に正しいですか？ |
|
投稿日時: 2007-10-24 19:06
チャブーンさん ご返信下さいまして本当に有難うございます。
「DC=AAA,DC＝BBB」というのは、LDAPBROWSERで取得した文字列です。 具体的には、LDAPBROWSERのconnectを作成する画面で、「FetchDNs」ボタンを クリックして取得した文字列をBaseDNといたしました。 ただ、このBaseDNで、ユーザ認証までは出来ましたので、ユーザのエントリ位置取得時 BaseDNも「DC=AAA,DC＝BBB」もこれでよいものかと思っていたのですが、 Active Directory のデフォルトコンテナの 「Users 」の中に「CN=34044」が登録されてい ますので、ユーザのエントリ位置取得時については、BaseDNは「CN=34044,CN=Users,DC=AAA,DC=BBB」 とすべきなのですね？ これはADの仕様としてそういう規則なのでしょうか？ 例えば、「users」の下に「CN=999999」というディレクトリを作成し、 「CN=999999」の中に、「CN=34044」 を登録されている場合、これに対して、以下の接続情報でADに問い合わせをしたとしましたら、 ・接続URL ：HTTP://ADサーバのIPアドレス：389 ・ドメイン ：AAA.BBB ・BaseDN ：「CN=34044,CN=Users,DC=AAA,DC=BBB」 ・フィルタ ：CN=34044 ・接続ユーザ：CN＝34044＠AAA.BBB 検索結果は、「CN=999999,CN=Users,DC=AAA,DC=BBB」という形で、34044のエントリ位置を取得する ことができますでしょうか？ |
|
投稿日時: 2007-10-25 02:45
チャブーンです。
まず私がいいたかったのは、本来の DN のうち「CN=Users」の部分について、「CN=USER」(s がない) と間違えておられるのではないか、ということでした。DN 文字列がちがっていれば、当然オブジェクトを呼び出すことはできません。 BaseDN については、他の LDAP v3 製品と同じ実装になりますので、DC=AAA,DC=BBB で問題ありません。検索時間を短縮するためには CN=Users,DC=AAA,DC=BBB の方がいいかもしれませんが。 本題ですが、単にフィルタが間違っているだけなら、検索結果が空となるだけですので、LDAP バインドの段階で失敗している可能性が高いと思います。「認証は成功した」と書かれていますが、根拠はなんでしょう？ 「接続ユーザ:CN＝34044＠AAA.BBB」とかかれていますが、このような CN はありません。あくまで「CN=34044,CN=Users,DC=AAA,DC=BBB」となり userPrincipalName 属性が 34044@aaa.bbb となります。 内容から kerberos 認証をされているのだと理解していますが、まず認証が本当にうまくいっているのか確認された方がいいかな、と思います。具体的にはパケットキャプチャでバインド認証時に成功しているかどうかが確認できるのではないでしょうか。 トラブル解決のため、シンプル認証を使って「CN=34044,CN=Users,DC=AAA,DC=BBB」でバインドさせることで切り分ける、という方法もあるかもしれません。 最後にお節介ですが、Active Directory で LDAP ディレクトリを管理者がこしらえた場合、ディレクトリ RDN は「OU=XXX」となり、CN=XXX とはなりません。「CN=Users」に関してはデフォルトで用意された特別なディレクトリとなり RDN が異なりますので、注意が必要です。 |
|
投稿日時: 2007-10-25 08:03
http://sdc.sun.co.jp/java/docs/j2se/1.4/ja/docs/ja/api/javax/naming/AuthenticationException.html
など検索するとわかりますし、AUTHENTIFICATION(認証） なので認証のエラーです。 JAVA特有なのか サーバー同士の設定に起因しているかわかりませんが 他のツール、（LDAPブラウザなど）で接続しても同じなのでしょうか？ また別マシンであれば、日時差が５分以内に収まってますでしょうか？ |
|
投稿日時: 2007-10-25 11:38
>>チャブーンさん
ご親切なご指導を頂きまして有難うございます。 ご指摘の意図、理解いたしました。申し訳ありませんでした。 BaseDNは、「DC=AAA,DC=BBB 」ということで、ただし検索効率を考慮し、「CN=Users,DC=AAA,DC=BBB 」でやってみるということですね。 有難うございます。 さて、「認証は成功した」の根拠でございますが、今回の認証プログラムでは、認証時に「InitialDirContext 」オブジェクトを生成するようにしているのですが ログをみたときに、「InitialDirContext 」オブジェクトの生成には成功し、次に「InitialDirContext 」のSearch処理に移っていましたので、認証は成功したという 解釈をしております。 処理の中では、「InitialDirContext 」オブジェクトの生成が成功したときは、trueとし、失敗時にはfalseに置き換えるようにしているのですが、 実際に間違ったパスワードを入力するとfalseとなります。これはユーザ：34044以外のユーザで試しても、パスワードの正誤に対する反応は 正常でした。 あと、「接続ユーザ:CN＝34044＠AAA.BBB」とかかれていますが」のご指摘ありがとうございます。 以下のやり方に変えることに致しました。 env.put(Context.SECURITY_AUTHENTICATION, "simple"); env.put(Context.SECURITY_PRINCIPAL, 34044@AAA.BBB); env.put(Context.SECURITY_CREDENTIALS, H0YYRT); 一度、これでトライいたいします！！ >>柴田たけおさん ご助言有難うございます。 一応、LdapBrowserでも試しております。 LdapBrowserではうまく、当該ユーザのエントリ位置が返ってくるのですが、 全く同じ接続文字列を使って、JSPのプログラムで行うと、認証はうまくいくのですが エントリー位置だけとれないという状態です。 ということは、接続時のJSPのソース内の記述規則が間違っているということも考えられますので、 まずは、チャブーンさんのご助言を参考にさせて頂いて、プログラム側のミスをさぐっていこうとおもって います。 ただ、プログラム側の記述も問題なかった場合、AD側で、例えば、AnonymousBIND認証を許可させて みて、どうか。。ということもやってみたいのですが、これをするにはAD側のどこをさわればよいのかが わからなく調べているところですが、これはこれで分かっていません。。（汗） |
|
投稿日時: 2007-10-25 11:47
>>「CN=Users」に関してはデフォルトで用意された特別なディレクトリとなり RDN が異なりますので、注意が必要です。
チャブーンさん これについてご教示頂きたいのですが、もともと客先のActiveDirectryでは「CN=Users」の下にユーザ が「CN=＊＊＊」という形で、登録されており、私もアレっ？って思ったのですが、この「CN=Users」の下にユーザを 登録した構造というのは、やはり一般的とはいえないのでしょうか？ 普通は、ルートサィックス（DC＝AAA、DC＝BBB）の下に、OU（部や課などのなんらかの組織単位）をつくって、 の中に、ここにユーザを登録していくと思うのですが、どうなのでしょうか？ また、チャブーンさんのご助言の中に、「注意が必要です」とございますが、どういった点に注意をもっておいた ほうがよろしいのでしょうか。 度々申し訳ございません。 |
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。