3

企業ポータルが AD からグループを取得できないユーザーがいます。

ポータル ログに次のエラーが表示されます。

javax.naming.PartialResultException: 未処理の継続参照の残りの名前 ''

このエラーと、このケースを説明していると思われる最良の症状とその解決方法を Google で検索しました。

1 人のユーザーのためだけに構成を変更したくないと仮定すると、この特定のユーザーのデータを修正するには、AD でユーザーのレコードを調べるときにこれをどのように認識できるか説明してもらえますか? これは彼のグループの割り当てと関係がありますか? はいの場合、何を探す必要がありますか?

4

4 に答える 4

7

私はちょうどこれに遭遇しました。

Context.REFERRAL キーを「follow」に設定するように InitialDirContext 環境を設定することで回避しました。

Javadocs によると、そのキーは「フォロー」、「無視」、または「スロー」のいずれかです。デフォルトは、使用するプロバイダーによって決まります。これはおそらく「スロー」です。

于 2013-03-01T17:58:15.537 に答える
4

API が伝えていることに関するもう少し詳しいデータについては、このリンクを参照してください: http://www.jspwiki.org/wiki/ActiveDirectoryIntegration

私はこの API の専門家ではありませんが、AD が何をしているかについてのドキュメントと知識に基づいて、少なくとも私が考えていることを説明できます。:)

AD は、このローカル サーバー/検索の外部にあるが要求の論理範囲内にある名前付けコンテキストを持つ検索を行うと、いわゆる「紹介」を返します。これは RFC 要求ごとです。紹介は、他にもデータがある可能性があるというアプリへのヒントと考えてください...つまり、ADサーバーは「これが私があなたのために持っている結果ですが、知っておくべきです、誰かがいます」と言っています他にももっとあるかもしれません...ここに行って調べてください。」 紹介は「エラー」ではなく、アプリへのヒントです。

それらに遭遇すると、LDAP API が例外をスローしているようです。上記で参照したドキュメントによると、それらを飲み込むか、紹介を追跡して、さらにデータがあるかどうかを調べることができるようです.

于 2012-08-31T22:47:43.603 に答える
0

また、私が見つけた問題の 1 つは、ldapContext の検索クエリ文字列が正しくないことでした。パラメータ スローの形式が間違っているために、不正なクエリが形成されます。

javax.naming.PartialResultException: Unprocessed Continuation Reference(s) remaining name ''

ただし、パラメータ Context.REFERRAL="follow" を追加すると、例外はスローされませんが、結果も返されません。

LDAP クエリ文字列へのパラメーターも、LDAP によって受け入れられているものと一致する必要があります。そうでない場合、同じエラーがスローされます。

于 2015-02-27T09:05:47.440 に答える