FBA拡張サイトのユーザーがNTLMユーザーを解決できるか

Question

クレーム認証を使用するSharePoint 2010エクストラネットWebアプリケーションがあります。

• イントラネットゾーンでは、混合認証（内部ADに対してNTLM、別のADに対してFBA）が使用されています。
• エクストラネットゾーンは、別個のADに対してのみFBAを使用します。

メンバSharePointグループにNTLMユーザーを持つサイトがあります。私たちはメンバーグループに限定された "Person"列を持つ図書館を持っています。 FBAユーザーは、アイテムメタデータを入力するときに、メンバーグループにあるNTLMユーザーを選択することができます。問題は、FBAユーザーがPeople Picker内のNTLMユーザーを見ることができますが、ユーザーがそれらを選択すると、ユーザーは解決されないということです。 NTLMをエクストラネットゾーンに追加することで、おそらくこれを回避することはできますが、可能であればこれを実行しないほうがいいと思います。

私の質問は以下のとおりです。これは、カスタムクレームプロバイダーが適切であろうシナリオ

ですか？

これはpeoplepicker-searchadforestsプロパティで解決できる問題ですか？ （私は、この物件が現実の世界の例の周りに頭を浮かべることができませんでした）

Answer 1

これは、私が人のピッカーが動作することを理解した方法です。私は100％ではないので、絶対的な真実のためにそれを取らないでください:)

基本的に、エクストラネットアプリケーションのコンテキストでは、すべての標準ピッカーは内部ADが存在することに完全に気づいていません。人選機で取得した「ヒット」は、SiteUsersリストやプロファイルデータベースにあります。

"これはpeoplepicker-searchadforestsプロパティで解決できる問題ですか？" 私はそうは思わない、あなたが人のピッカー検索を行うことができても、他の広告はいくつかのオブジェクトに人の許可を加えることができるように、しかしFBAクレームのプレフィックスを付けて、これは、NTLMを使用してログインしたときにユーザーと同じではありません。 （NTLMとクレームでサインインしたユーザーは技術的に異なるユーザーです）

"これはカスタムクレームプロバイダが適切なシナリオですか？ 私はそうは思わない:(

あなたが作った人のピッカー（つまり、あなたがカスタムページやウェブパーツを持っているか、人のピッカーを持っている人）のためにできるトリックには、いくつかのプロパティがありますたとえば、現在のユーザーが外部アプリケーションにログインしているにもかかわらず、内部アプリケーションのコンテキスト内でピッカーを動作させる「WebApplication」などのプロパティを設定することができます。

エクストラネットアプリケーションでNTLMメンバーシッププロバイダーを有効にする方法はありますが、エンドユーザー認証を実際に有効にすることはできませんが、不可能ではありませんが、しかし、やってください。