統合認証を使用するイントラネット ポータルを開発していますが、サイトのいくつかのセクションがドメイン外のユーザーに公開されます。これらのユーザーには、匿名アクセスを使用する予定です。ただし、アプリケーション全体の表示ロジックは、ポータルにログインしているユーザーに基づいているため、このアプローチには完全には満足していません。URL は両方のタイプのユーザーに対して同じである必要があり、両方の環境間の移行がシームレスである必要があります。
ページでユーザー コントロールを使用して認証を試みましたが、うまくいきませんでした。ページに到達すると、標準の Windows 認証の灰色のボックスが表示されます。
HTTP アプリケーションのように IIS レベルで要求を傍受する方法はありますか? 該当する場合は、匿名アクセスを無効にし、認証されていないユーザーに対しては、最小限の特権を持つドメイン アカウントで偽装し、ホームページにリダイレクトします。
SharePoint は、認証の種類を混在させるという、あなたが説明したシナリオ向けに実際には設計されていません。Web アプリケーションを1 種類の認証専用にします。次に、その Web アプリケーションを「拡張」して、別のアドレスで別のタイプの認証を使用できます。たとえば、イントラネット ポータルは Windows 認証を使用します。次に、別のポートまたはドメイン名で匿名認証を使用するように拡張できます。
説明するオプションの 1 つは、2 つの別個の Web アプリケーションを構成することです。1 つは、認証が必要なユーザー用です。もう 1 つは匿名アクセス用です。適切な場所でコンテンツを構成し、必要に応じて 2 つの間をリンクします。このアプローチを使用する場合、ドメイン内のユーザーは、認証済みサイトに接続するときにログイン プロンプトを受け取るべきではありません。ドメイン外のユーザーにはログイン ボックスが表示され、アクセスできなくなります。
イントラネットにアクセスする必要がある場合は、ドメイン外のユーザーに対してフォーム認証を使用することを検討してください。(ここでも、サイトの「フォーム認証」部分が一意のドメイン名またはポートに拡張されます。)これは、最初の接続時に、ページのフォームに資格情報を入力するように求められることを意味します。
Authentication Resource Centerで認証の詳細を参照してください。
いくつかの最終的なポイント... 独自のコントロールを作成するのではなく、SharePoint の既定の認証メカニズムを使用できる場合は、十分にテストされており、安全であるため、それらを使用してください。また、必要なことを行う方法が他にないことが確実でない限り、SharePoint の IIS 設定を変更しようとしないでください。SharePoint はこれら自体を定期的に更新し、変更を上書きする可能性があります (または、他の方法で問題を引き起こす可能性があります)。