Office ドキュメント内の、SSO Web サイトへのハイパーリンクをクリックしたときに、ログオン ページまたはエラー ページにリダイレクトされる、あるいは認証情報の入力が求められる


現象


Microsoft Office ドキュメント内のハイパーリンクをクリックしたときに、次のような動作が発生して、要求したページを開けないことがあります。
  • ログオン ページまたはエラー ページにリダイレクトされる。
  • 認証情報の入力が求められる。
通常、この現象は、次の条件に該当する場合に発生します。
  • Web ブラウザー以外の場所で、編集モードで Office ドキュメントを開いた。
  • ハイパーリンクの Web サイトで、HTTP セッション Cookie を利用してクライアントを識別するシングル サインオン (SSO) 認証システムが使用されている。 既にユーザーの資格情報を入力済みであるのに、再度ユーザーの資格情報の入力が求められる。

原因


Web 作成やコラボレーションをサポートしているサーバー上の Web サイトでは、Office を使用したドキュメントの編集や作成が行えます。 まず最初に、Office は Web サーバーとの通信を試行します。 次に、Office は Microsoft Hyperlink Library (Hlink.dll) と URLMON API を使用して、リソースに直接バインドしようとします。 詳細については、次の「マイクロソフト サポート技術情報」(Microsoft Knowledge Base) の資料番号をクリックしてください。

838028 Office 2003 で Web サイトからドキュメントを開くときの仕組み

Office が Web ページ要求を送信したときに、SSO システムの Web サイト ログオン ページにリダイレクトされることがあります。 既に Web ブラウザー セッションに対してユーザーの資格情報を入力してあっても、Office セッションは独立したセッションであるため、この現象が発生します。

両セッションはそれぞれ独立しているため、セッション Cookie は共有されません。 もっぱらセッション Cookie の情報に頼っている SSO システムでは、同じユーザーが複数のセッションを行き来するため、SSO システムが機能していないように見えることがあります。 クライアント デスクトップ上の複数のブラウザーや Web 対応アプリケーションにまたがった SSO 認証をサポートするように設計されていない SSO システムの場合、この現象は SSO システムの基本設計上の制限です。 Office は完全に Web 対応のアプリケーションであるため、クライアントによってインストールされた Web 対応クライアントが Office アプリケーションだけであると、上記の問題が Office アプリケーションに固有の問題であるように見られることがあります。 しかし、この問題の根本的な原因は、Microsoft Office に限定されるものではなく、サード パーティのソフトウェアを使用している場合でもこの問題は発生することがあります。

回避策


この問題は、Web で使用されている SSO システムの制限です。 ただし、以下のいずれかの方法を使用することで、SSO で保護された Web サイトに対する現状の影響を軽減できる場合があります。

Internet Explorer から Office へのハイパーリンク

Web ページ上のハイパーリンクによって Office ファイルが開かれたときにこの問題が発生し、その Web ページが Internet Explorer でホストされている場合は、コンテンツをインライン ナビゲーションとしてではなく、読み取り専用ダウンロードとして明示的にマークすることによって、この問題を回避できます。

これを行うには、Office ファイル コンテンツに対する GET 応答にカスタム HTTP ヘッダーを追加します。 「Content-Disposition: Attachment」ヘッダーを追加します。 GET 応答にこのヘッダーが含まれていると、Internet Explorer は、ダウンロードを開くのか保存するのかを尋ねるプロンプトを表示します。 ダウンロードを開くことを選択すると、ファイルは Internet Explorer の一時ファイル キャッシュから読み取り専用で開きます。 このファイルをローカルで変更して保存することができます。 ただし、このファイルをサーバーに保存したり、Web サイトの Web サービスを使用して共同作業したりすることはできません。 したがって、このソリューションは、ファイルを読み取り専用にすることを目的とする場合にのみ機能します。

「Content-Disposition」ヘッダーは、動的に生成されたコンテンツを扱っている場合は、Microsoft アクティブ サーバー ページ (ASP)、Microsoft ASP.NET、または ISAPI のコードを使用して設定できます。 静的コンテンツの場合は、IIS マネージャーと IIS メタベースを使用して、所定のファイルまたはフォルダー用のヘッダーを構成できます。Content-Disposition HTTP ヘッダーの詳細については、次の「マイクロソフト サポート技術情報」(Microsoft Knowledge Base) の資料番号をクリックしてください。

260519 既知の MIME タイプに対して [ファイルのダウンロード] ダイアログ ボックスを開く方法

Office から Internet Explorer またはその他の Web ブラウザーへのハイパーリンク

Office ドキュメント内の、直接 HTML Web コンテンツを開くハイパーリンク、または HTML コンテンツにリダイレクトされるハイパーリンクをクリックしたときにこの問題が発生する場合は、Office からハイパーリンクに直接バインドするのではなく、ブラウザーにハイパーリンク ナビゲーションを送信するためのレジストリ キーを有効にすることによって、この問題を回避できます。 詳細については、次の「マイクロソフト サポート技術情報」(Microsoft Knowledge Base) の資料番号をクリックしてください。

218153 ハイパーリンクをクリックすると、"インターネット サーバーまたはプロキシ サーバーが見つかりません" というエラー メッセージが表示される

注: インストールされている Office のバージョンに関係なく、マイクロソフト サポート技術情報 218153 に指定されているとおりの正確な場所に、レジストリ キーを追加してください。

このレジストリ設定を使用した場合、Office で使用される HLINK コンポーネントは既定の Web ブラウザーでハイパーリンクを開きます。 このレジストリ設定は、Office だけでなく、すべての HLINK クライアントに影響します。 そのため、このレジストリ キーは慎重に使用してください。 この方法を使用した場合に発生する可能性のある問題の詳細については、次の「マイクロソフト サポート技術情報」(Microsoft Knowledge Base) の資料番号をクリックしてください。

280680 Office ドキュメントへのハイパーリンクが動作しない

詳細情報


この問題を完全に解決するため、マイクロソフトでは SSO プロバイダーに対して、Web 作成や、複数セッションを使用するクライアントを考慮に入れたシステムを開発することを推奨しています。 この構成にすると、SSO システムの複雑さが増します。 しかし、この構成にすると、クライアント側の利便性も高まります。 マイクロソフトでは現在、長期的なソリューションに向け、主要 SSO プロバイダー各社と作業を行っています。

さらにマイクロソフトでは、次のようなシナリオを予測し対処するため、エンド ユーザーがどのように Office を使用しているか調査を続けています。
  • ユーザーの目的は、ハイパーリンクを読み取り専用モードで開くことである。 このシナリオでは、ハイパーリンクがブラウズ モードで開きます。
  • ユーザーの目的は、コンテンツを変更することである。 このシナリオでは、編集やコラボレーションのための新しいセッションが必要です。
こうした構成変更により、「現象」に記載されている問題の影響が軽減する可能性があります。 また、こうした構成変更により、複数セッション クライアントを含む構成をサポートしていない SSO サイトにアクセスしたユーザーにとって、柔軟性が増す可能性もあります。

SSO デザイナーや SSO 開発者であれば、複数セッション クライアントのサポートを追加できます。 たとえば、次のような方法を使用できます。
  • 永続的な Cookie 情報とセッション Cookie 情報を使用して、ある 1 つのクライアントがデスクトップ上のアプリケーション間でセッションを行き来したタイミングを特定する。 次に、クライアントを単一セッションに転送して戻すための、あるいは新しいセッションを認証するための Web 応答を提供する。
  • クライアント側のコンポーネントを使用して、統合認証システムを作成する。 この統合認証システムを使用して、同じユーザー認証トークンを使用して開始されたすべてのプロセスを認証する。
  • 証明書か、または別の、セキュリティが強化されつつも永続的な識別方法を使用して、クライアントを認証する。
  • 複数セッション クライアント要求であり得る HTTP 要求の場合は、サーバー側のリダイレクト応答ではなく、クライアント側のリダイレクト応答を発行する。 たとえば、HTTP 302 応答ではなく、HTTP スクリプトまたは META REFRESH タグを送信する。 この変更により、クライアントが強制的にユーザーの既定の Web ブラウザーに戻る。 そのため、既定のブラウザー セッションで呼び出しを処理することができ、単一の、読み取り専用セッションで呼び出しを保持できる。

    この方法では、編集は可能になりません。 しかし、この方法により、SSO システムが複数セッション クライアントを処理しないことが明確になり、クライアントが既定のブラウザー セッションのみに留まることが求められます。
この構成変更を行うための的確なアプローチは、システム設計の目標と、クライアントのデスクトップ上に用意する統合のレベルによって異なります。