まず、少し背景：私たちはDOMAIN_A.LOCALに、サーバー上でホストされているとの認証に統合Windows認証を使用するように設定されたWSS 3.0に基づいて、イントラネットサイトを持っていますActive Directoryユーザーアカウントに対してユーザーはDOMAIN_A.LOCALです。のSharePoint（WSS）の認証
ユーザーが異なるからADアカウントを使用してWindowsにログインしてPCからサイトにアクセスしようとすると、この設定はDOMAIN_A.LOCAL からADアカウントを使用してWindowsにログインしているユーザーのためにうまく動作しますが、ドメイン（すなわちDOMAIN_B.LOCAL）以下の問題が発生します。
ユーザーが手動でDOMAIN_A \ユーザー名と資格情報を入力する必要がありますだけではなくUserNameがそうでないので、Internet Explorerが自動的にDOMAIN_Bを挿入し、認証が失敗します。
ログインすると、ブラウザーでクライアントアプリケーションに認証を渡す必要がある場合（編集用に開くためにドキュメントライブラリ内のMicrosoft Officeドキュメントをクリックするなど）、ユーザーが表示されます。その無効な資格情報（おそらくDOMAIN_Bは）ので、手動で再びそのDOMAIN_A資格情報を入力するようにユーザーを強制的に、自動的に渡されます。
（基本クリアテキスト認証を使用する場合に行うことができますように）ので、統合Windows認証を使用した場合の動作の「デフォルトドメイン」タイプを実装するためにどのような方法があります：
私の質問は、このですDOMAIN_B上のユーザーは、自分のユーザー名の前DOMAIN_Aをドメインに入らない場合は彼らのために自動的に挿入されていること？
もちろん、私はこの展開に致命的な欠陥があるかもしれないことを認識しているので、私は別の実装の提案も受け付けています。
要約すると、主な問題は、1つのSharePointサイトで同じコンテンツにアクセスする必要のある2種類の異なるユーザーが原因です。 DOMAIN_Aのユーザーは、すべて自分でWindowsにログインするフルタイムワークステーションを持っています。 DOMAIN_B、ユーザーが必要に応じて資格情報を提供しなければならないため、要件 - DOMAIN_Bのユーザーは、残念ながらSharePointで何の権限を持たない一般的な「キオスク」タイプのアカウントを使用してログオンしている共有コンピュータを使用する必要がありますSharePointの特定のページにアクセスするときにする「キオスク」のユーザーマニュアル認証の量を最小限に抑えながら、私は DOMAIN_B DOMAIN_Aの「静」のユーザーに対して統合Windows認証の利便性を維持したいと思い我慢しなければなりません。
* DOMAIN_B *を信頼して問題を解決できないその他の理由は、これらのアカウントにSharePointの権限がないことです。 * DOMAIN_B *アカウントは、個々のユーザーではなく、キオスクワークステーションを識別する一般的なログインです。 アプリケーションを新しいゾーンに拡張することを提案したら、別のゾーンを介して同じコンテンツに異なる認証方法を使用させることは可能ですか？もしそうなら、それは私が必要とするものかもしれません... –
はい、それはまさに私が意味するものです。 ゾーンの計画に関するテクニックの記事、ISAを拡張して公開する方法については、次のURLを参照してください。http://technet.microsoft.com/en-us/library/cc288609.aspx – shufler
ありがとう、Jason - これは必要なものです。私は今この設定をテストしています。 –